Motion control systems

ABSTRACT

A system for motion control in which an application is developed that is independent from the actual motion control hardware used to implement the system. The system comprises a software system that employs an application programming interface comprising component functions and a service provider interface comprising driver functions. A system programmer writes an application that calls the component functions. Code associated with the component functions relates these functions to the driver functions. A hardware designer writes driver code that implements the driver functions on a given motion control hardware product. The driver functions are separated into core and extended driver functions. All software drivers implement the core driver functions, while the software drivers need not contain code for implementing the extended driver functions. If the software driver does not contain code to implement an extended driver function, the functionality of the extended driver function is obtained through a combination of core driver functions. The system programmer may also select one or more streams that allow the control commands to be communicated to, and response data to be communicated from, motion control hardware.

RELATED APPLICATIONS

This is a continuation of U.S. patent application Ser. No. 10/021,669filed on Dec. 10, 2001, which is a continuation of U.S. patentapplication Ser. No. 09/191,981 filed on Nov. 13, 1998, now abandoned,which is a continuation of U.S. patent application Ser. No. 08/656,421filed on May 30, 1996 now U.S. Pat. No. 5,867,385, which is acontinuation-in-part of U.S. patent application Ser. No. 08/454,736filed on May 30, 1995 now U.S. Pat. No. 5,691,897.

Priority is also claimed from U.S. patent application Ser. No.09/795,777 filed on Feb. 27, 2001, which is incorporated by reference inits entirety and which is a continuation of U.S. patent application Ser.No. 09/205,627 filed on Dec. 3, 1998, now U.S. Pat. No. 6,209,037, whichclaims benefit of U.S. Provisional Patent Application Ser. No.60/067,466 filed on Dec. 4, 1997, and which is a continuation of U.S.patent application Ser. No. 09/191,981 filed on Nov. 13, 1998, nowabandoned, which is a continuation of U.S. patent application Ser. No.08/656,421 filed on May 30, 1996 now U.S. Pat. No. 5,867,385, which is acontinuation-in-part of U.S. patent application Ser. No. 08/454,736filed on May 30, 1995 now U.S. Pat. No. 5,691,897.

Priority is also claimed from U.S. patent application Ser. No.09/633,633 filed on Aug. 7, 2000, which is incorporated by reference inits entirety and which is a continuation of U.S. patent application Ser.No. 08/656,421 filed on May 30, 1996 now U.S. Pat. No. 5,867,385, whichis a continuation-in-part of U.S. patent application Ser. No. 08/454,736filed on May 30, 1995 now U.S. Pat. No. 5,691,897.

TECHNICAL FIELD

The present invention relates to motion control systems and, moreparticularly, to interface software that facilitates the creation ofhardware independent motion control software.

BACKGROUND OF THE INVENTION

The purpose of a motion control device is to move an object in a desiredmanner. The basic components of a motion control device are a controllerand a mechanical system. The mechanical system translates signalsgenerated by the controller into movement of an object.

While the mechanical system commonly comprises a drive and an electricalmotor, a number of other systems, such as hydraulic or vibrationalsystems, can be used to cause movement of an object based on a controlsignal. Additionally, it is possible for a motion control device tocomprise a plurality of drives and motors to allow multi-axis control ofthe movement of the object.

The present invention is of particular importance in the context of amechanical system including at least one drive and electrical motorhaving a rotating shaft connected in some way to the object to be moved,and that application will be described in detail herein. But theprinciples of the present invention are generally applicable to anymechanical system that generates movement based on a control signal. Thescope of the present invention should thus be determined based on theclaims appended hereto and not the following detailed description.

In a mechanical system comprising a controller, a drive, and anelectrical motor, the motor is physically connected to the object to bemoved such that rotation of the motor shaft is translated into movementof the object. The drive is an electronic power amplifier adapted toprovide power to a motor to rotate the motor shaft in a controlledmanner. Based on control commands, the controller controls the drive ina predictable manner such that the object is moved in the desiredmanner.

These basic components are normally placed into a larger system toaccomplish a specific task. For example, one controller may operate inconjunction with several drives and motors in a multi-axis system formoving a tool along a predetermined path relative to a workpiece.

Additionally, the basic components described above are often used inconjunction with a host computer or programmable logic controller (PLC).The host computer or PLC allows the use of a high-level programminglanguage to generate control commands that are passed to the controller.Software running on the host computer is thus designed to simplify thetask of programming the controller.

Companies that manufacture motion control devices are, traditionally,hardware oriented companies that manufacture software dedicated to thehardware that they manufacture. These software products may be referredto as low level programs. Low level programs usually work directly withthe motion control command language specific to a given motion controldevice. While such low level programs offer the programmer substantiallycomplete control over the hardware, these programs are highly hardwaredependent.

In contrast to low-level programs, high-level software programs,referred to sometimes as factory automation applications, allow afactory system designer to develop application programs that combinelarge numbers of input/output (I/O) devices, including motion controldevices, into a complex system used to automate a factory floorenvironment. These factory automation applications allow any number ofI/O devices to be used in a given system, as long as these devices aresupported by the high-level program. Custom applications, developed byother software developers, cannot be developed to take advantage of thesimple motion control functionality offered by the factory automationprogram.

Additionally, these programs do not allow the programmer a great degreeof control over the each motion control device in the system. Eachprogram developed with a factory automation application must run withinthe context of that application.

PRIOR ART

In the following discussions, a number of documents are cited that arepublicly available as of the filing date of the present invention. Withmany of these documents, the Applicant is not aware of exact publishingdates. The citation of these documents should thus not be considered anadmission that they are prior art; the Applicant will take the stepsnecessary to establish whether these documents are prior art ifnecessary.

As mentioned above, a number of software programs currently exist forprogramming individual motion control devices or for aiding in thedevelopment of systems containing a number of motion control devices.

The following is a list of documents disclosing presently commerciallyavailable high-level software programs: (a) Software Products ForIndustrial Automation, iconics 1993; (b) The complete, computer-basedautomation tool (IGSS), Seven Technologies A/S; (c) OpenBatch ProductBrief, PID, Inc.; (d) FIX Product Brochure, Intellution (1994); (e)Paragon TNT Product Brochure, Intec Controls Corp.; (f) WEB 3.0 ProductBrochure, Trihedral Engineering Ltd. (1994); and (g) AIMAX-WIN ProductBrochure, TA Engineering Co., Inc. The following documents disclosesimulation software: (a) ExperTune PID Tuning Software, GerryEngineering Software; and (b) XANALOG Model NL-SIM Product Brochure,XANALOG.

The following list identifies documents related to low-level programs:(a) Compumotor Digiplan 1993-94 catalog, pages 10-11; (b) AerotechMotion Control Product Guide, pages 233-34; (c) PMAC Product Catalog,page 43; (d) PC/DSP-Series Motion Controller C Programming Guide, pages1-3; (e) Oregon Micro Systems Product Guide, page 17; (f) PrecisionMicrocontrol Product Guide.

The Applicants are also aware of a software model referred to as WOSAthat has been defined by Microsoft for use in the Windows programmingenvironment. The WOSA model is discussed in the book Inside Windows 95,on pages 348-351. WOSA is also discussed in the paper entitled WOSABackgrounder: Delivering Enterprise Services to the Windows-basedDesktop. The WOSA model isolates application programmers from thecomplexities of programming to different service providers by providingan API layer that is independent of an underlying hardware or serviceand an SPI layer that is hardware independent but service dependent. TheWOSA model has no relation to motion control devices.

The Applicants are also aware of the common programming practice inwhich drivers are provided for hardware such as printers or the like; anapplication program such as a word processor allows a user to select adriver associated with a given printer to allow the application programto print on that given printer.

While this approach does isolates the application programmer from thecomplexities of programming to each hardware configuration in existence,this approach does not provide the application programmer with theability to control the hardware in base incremental steps. In theprinter example, an application programmer will not be able to controleach stepper motor in the printer using the provided printer driver;instead, the printer driver will control a number of stepper motors inthe printer in a predetermined sequence as necessary to implement agroup of high level commands.

The software driver model currently used for printers and the like isthus not applicable to the development of a sequence of control commandsfor motion control devices.

OBJECTS OF THE INVENTION

From the foregoing, it should be clear that one primary object of theinvention is to provide improved methods and devices for moving objects.

Another more specific object of the present invention is to obtainmethods and apparatus for designing and deploying motion control devicesin which these methods and apparatus exhibit a favorable mix of thefollowing characteristics:

(a) allow the creation of high-level motion control programs that arehardware independent, but offer programmability of base motionoperations;

(b) hide the complexities of programming for multiple hardwareconfigurations from the high-level programmer;

(c) can easily be extended to support additional hardwareconfigurations; and

(c) transparently supports industry standard high-level programmingenvironments.

SUMMARY OF THE INVENTION

The present invention is, in one form, a method of moving an objectcomprising the steps of developing a high-level motion controlapplication program comprising a sequence of component functions thatdescribe a desired object path, correlating these component functionswith driver functions, selecting a software driver for the specifichardware configuration being controlled, generating control commandsfrom the driver functions and the software driver associated with thehardware configuration being controlled, and controlling a motioncontrol device based on the control data to move the object along thedesired object path.

In another form, the present invention is a method of generating asequence of control commands for controlling a motion control devices tomove an object along a desired path. An application program comprising aseries of component functions defines a sequence of motion steps thatmust be performed by the motion control device to move the object alongthe desired path. The component functions contain code that relates thecomponent functions to driver functions. The driver functions areassociated with, or contain, software drivers containing driver code forimplementing the motion steps on a given motion control device. Thecontrol commands are generated based on the application program and thedriver code associated with a given motion control device.

The use of component functions that are separate from driver functionsisolates the programmer from the complexities of programming to aspecific motion control device. This arrangement also allows a givenapplication program to be used without modification for any motioncontrol device having a software driver associated therewith.

The driver functions are grouped into core driver functions and extendeddriver functions. All software drivers must support the core driverfunctions; the software drivers may also support one or more of theextended driver functions, although this is not required.

Where the software drivers do not support the extended driver functions,the functionality associated with the extended driver functions cannormally be simulated using some combination of core driver functions.In this case, the method of the present invention comprises the steps ofdetermining which of the extended driver functions are not supported bythe software driver and, where possible, substituting a combination ofcore driver functions. In some cases, the functionality of an extendeddriver function cannot be emulated using core driver functions, and thisfunctionality is simply unavailable to the programmer.

The use of core driver functions to emulate extended driver functionsprovides functionality where none would otherwise exist, but thepreferred approach is to provide a software driver that supports each ofthe extended driver functions. When an extended driver function issupported and not emulated, the task being performed will normally beaccomplished more quickly and accurately.

Additionally, to simplify the use of emulated extended driver functions,the method of the present invention further comprises the steps ofdetermining which, if any, extended driver functions are not supportedby the software driver for a given hardware configuration, developing afunction pointer table of both unsupported extended driver functions andsupported extended driver functions, and consulting the table each timean extended driver function is called to determine whether that extendeddriver function must be emulated. In this manner, the process of callingthe sequence of core driver functions employed to emulate theunsupported extended driver functions is optimized.

As the control commands are generated as described above, they may beused to control a motion control device in real time or they may bestored in a file for later use. Preferably, the method of the presentinvention comprises the step of providing a number of streams containingstream code. Each stream is associated with a destination of controlcommands, and the stream code of a given stream dictates how the controlcommands are to be transferred to the destination associated with thatgiven stream. The user is thus provided the opportunity to select one ormore streams that dictate the destination of the control commands.

To help isolate the programmer from hardware specific complexities, themethod of the present invention may comprise the additionaladministrative steps such as selecting a driver associated with aparticular motion control device and/or translating units required todefine the motion control system into the particular system of unitsemployed by a given motion control device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a system interaction map of a motion control systemconstructed in accordance with, and embodying, the principles of thepresent invention;

FIG. 2 is a module interaction map of a motion control component of thesystem shown in FIG. 1;

FIG. 3 is an object interaction map of the component shown in FIG. 2;

FIGS. 4 through 8 are scenario maps of the component shown in FIG. 2;

FIG. 9 is an interface map of the component shown in FIG. 2;

FIG. 10 is a data map showing one exemplary method of accessing the datanecessary to emulate extended driver functions using core driverfunctions;

FIG. 11 is a module interaction map of the driver portion of the systemshown in FIG. 1;

FIG. 12 is an object interaction map of the driver portion shown in FIG.11;

FIGS. 13 through 20 are scenario maps related to the driver shown inFIG. 11;

FIG. 21 is an interface map for the driver shown in FIG. 11;

FIG. 22 is a module interaction map of the streams used by the systemshown in FIG. 1;

FIG. 23 is an object interaction map of the streams shown in FIG. 22;

FIGS. 24 through 32 are scenario maps of the streams shown in FIG. 22;

FIG. 33 is an interface map of the objects comprising the stream shownin FIG. 22;

FIG. 34 is a module interaction map of the driver stub portion of thesystem shown in FIG. 1;

FIG. 35 is an object interaction map of the driver stub shown in FIG.34;

FIGS. 36 through 38 are scenario maps of the driver stub shown in FIG.34;

FIG. 39 is an interface map of the driver stub portion shown in FIG. 34;

FIG. 40 is a module interaction map of the driver administrator portionof the system shown in FIG. 1;

FIG. 41 is an object interaction map of the driver administrator shownin FIG. 40;

FIGS. 42 through 49 are scenario maps relating to the driveradministrator shown in FIG. 40;

FIG. 50 is an interface map of the objects that comprise the driveradministrator shown in FIG. 40;

FIG. 51 is a module interaction map of the driver administrator CPLapplet portion of the system shown in FIG. 1;

FIG. 52 is an object interaction map of the driver administrator CPLapplet shown in FIG. 51;

FIGS. 53 through 57 are scenario maps related to the driveradministrator CPL applet shown in FIG. 51;

FIG. 58 depicts a Module Interaction-Map showing all binary modules thatinteract with the driver and how they interact with one another;

FIG. 59 depicts an Object Interaction-Map which corresponds to themodule interaction map of FIG. 58 expanded to display the internal C++objects making up the language driver 44, and how these objects interactwith one another;

FIGS. 60-65 depict a number of Scenario Maps that display theinteractions taking place between the C++ objects involved duringcertain processes;

FIG. 66 depicts an interface map that describes the interfaces exposedby the language driver component 44, all data structures used, and thedefinitions of each C++ class used; and

FIG. 67 depicts a table illustrating how a typical database employed bythe language driver 44 may be constructed.

DETAILED DESCRIPTION OF THE INVENTION

Referring now to the drawing, depicted therein at 10 in FIG. 1 is amotion control system constructed in accordance with, and embodying, theprinciples of the present invention. This system 10 comprises a personalcomputer portion 12 having a hardware bus 14, a plurality of motioncontrol hardware controllers 16 a, 16 b, and 16 c, and mechanicalsystems 18 a, 18 b, and 18 c that interact with one or more objects (notshown) to be moved.

The personal computer portion 12 of the system 10 can be any systemcapable of being programmed as described herein, but, in the preferredembodiment, is a system capable of running the Microsoft Windowsenvironment. Such a system will normally comprise a serial port inaddition to the hardware bus 14 shown in FIG. 1.

The hardware bus 14 provides the physical connections necessary for thecomputer 12 to communicate with the hardware controllers 16. Thehardware controllers 16 control the mechanical system 18 to move in apredictable manner. The mechanical system 18 comprises a motor or thelike the output shaft of which is coupled to the object to be moved. Thecombination of the hardware controllers 16 a, 16 b, and 16 c and themechanical systems 18 a, 18 b, and 18 c forms motion control devices 20a, 20 b, and 20 c, respectively.

The hardware bus 14, hardware controllers 16, and mechanical systems 18are all well-known in the art and are discussed herein only to theextent necessary to provide a complete understanding of the presentinvention.

The personal computer portion 12 contains a software system 22 thatallows an application user 24 to create software applications 26 thatcontrol the motion control devices 20.

More particularly, based on data input by the user 24 and the contentsof the application program 26, the software system 22 generates controlcommands that are transmitted by one or more streams such as thoseindicated at 28 a, 28 b, 28 c, and 28 d. The streams 28 transmit controlcommands incorporating the hardware specific command language necessaryto control a given motion control device to perform in a desired manner.As will be discussed in more detail below, the streams 28 implement thecommunication protocol that allows the control commands to reach theappropriate motion control device 28 via an appropriate channel (i.e.,PC bus, serial port).

Using the system 22, the application program 26 is developed such thatit contains no code that is specific to any one of the exemplaryhardware controllers 16. In the normal case, the application program 26,and thus the user 24 that created the program 26, is completely isolatedfrom the motion control devices 20. The user 24 thus need know nothingabout the hardware specific command language or communication protocolassociated with each of these devices 20; it may even be possible thatthe command language of one or more of the hardware controllers 16 wasnot defined at the time the application program 26 was created.

The software system 22 comprises a combination of elements that allowthe application program 26 to be completely isolated from the hardwarecontrollers 16. In the following discussion, the framework of thesoftware system 22 will be described in terms of a method of moving anobject and/or a method of generating control commands. After thisgeneral discussion, each component of the system 22 will be described indetail in a specific operating environment.

I. Method of Generating Control Commands for Controlling a MotionControl Device to Move an Object

Initially, it should be noted that, in most situations, the methoddescribed in this section will normally but not necessarily involve thelabors of at least two and perhaps three separate software programmers:a software system designer; a hardware designer familiar with theintricacies of the motion control device; and a motion control systemdesigner. The application user 24 discussed above will normally be themotion control system designer, and the roles of the software systemdesigner and hardware designer will become apparent from the followingdiscussion.

The software system designer develops the software system 22. Thesoftware system designer initially defines a set of motion controloperations that are used to perform motion control. The motion controloperations are not specifically related to any particular motion controldevice hardware configuration, but are instead abstract operations thatall motion control device hardware configurations must perform in orderto function.

Motion control operations may either be primitive operations ornon-primitive operations. Primitive operations are operations that arenecessary for motion control and cannot be simulated using a combinationof other motion control operations. Examples of primitive operationsinclude GET POSITION and MOVE RELATIVE, which are necessary for motioncontrol and cannot be emulated using other motion control operations.Non-primitive operations are motion control operations that do not meetthe definition of a primitive operations. Examples of non-primitiveoperations include CONTOUR MOVE, which may be emulated using acombination of primitive motion control operations.

Given the set of motion control operations as defined above, thesoftware system designer next defines a service provider interface (SPI)comprising a number of driver functions. Driver functions may be eithercore driver functions or extended driver functions. Core driverfunctions are associated with primitive operations, while extendeddriver functions are associated with non-primitive operations. As withmotion control operations, driver functions are not related to aspecific hardware configuration; basically, the driver functions defineparameters necessary to implement motion control operations in a genericsense, but do not attach specific values or the like to theseparameters. The SPI for the exemplary software system 22 is attachedhereto as Appendix A.

The software system designer next defines an application programminginterface (API) comprising a set of component functions. For thesecomponent functions, the software system designer writes component codethat associates at least some of the component functions with at leastsome of the driver functions. The relationship between componentfunctions and driver functions need not be one to one: for example,certain component functions are provided for administrative purposes anddo not have a corresponding driver function. However, most componentfunctions will have an associated driver function. The API for theexemplary software system 22 is attached hereto as Appendix B.

The overall software model implemented by the software program 22 thuscontains an API comprising component functions and an SPI comprisingdriver functions, with the API being related to the SPI by componentcode associated with the component functions.

In order for the system 22 to generate the control commands, at leasttwo more components are needed: the application program 26 and at leastone software driver such as the drivers indicated at 30 a, 30 b, and 30c in FIG. 1.

The software drivers 30 are normally developed by a hardware designerand are each associated with a single motion control device. Thehardware designer writes driver code that dictates how to generatecontrol commands for controlling the motion control device associatedtherewith to perform the motion control operations associated with atleast some of the driver functions.

In the exemplary software system 22, the software drivers 30 a, 30 b,and 30 c are associated with the motion control devices 20 a, 20 b, and20 c, respectively. As a software driver exists for each of the motioncontrol devices 20 a, 20 b, and 20 c, these devices 20 a, 20 b, and 20 cform a group of supported motion control devices.

A careful review of the framework of the software system 22 as describedabove will illustrate that, of all the components of this system 22,only the software drivers 30 are hardware dependent.

The motion control system designer, normally also the user 24, developsthe application program 26. The application program 26 comprises asequence of component functions arranged to define the motion controloperations necessary to control a motion control device to move anobject in a desired manner. The application program 26 is anyapplication that uses the system 22 by programming the motion controlcomponent 35. Applications may program the system 22 either through OLEAutomation or by using any of the custom OLE interfaces making up theAPI.

As mentioned above, the component code associates many of the componentfunctions with the driver functions, and the driver functions define theparameters necessary to carry out the motion control operations. Thus,with appropriately ordered component functions, the application program26 contains the logic necessary to move the object in the desiredmanner.

Once the application program 26 has been written and the softwaredrivers 30 have been provided, the user 24 selects at least one motioncontrol device from the group of supported motion control devices 20 a,20 b, and 20 c. Using a driver administrator module 32, the user 24 thenselects the software driver associated with the selected motion controldevice. This driver administrator module 32 is used to install,uninstall, register, and setup each stream.

As currently implemented, the driver administrator 32 allows only onesoftware driver to be selected. In future versions of the softwaresystem 22, the driver administrator will allow the user to select one ormore software drivers.

The software system 22 thus generates control commands based on thecomponent functions contained in the application program 26, thecomponent code associated with the component functions, and the drivercode associated with the selected software driver 28.

As the control commands are being generated as described above, they maybe directly transmitted to a motion control device to control thisdevice in real time or stored in an output file for later use. Thesoftware system 22 employs the streams 28 to handle the transmission ofthe control commands to a desired destination thereof.

In the exemplary system 22, the destinations of the control commands maybe one or more of an output file 34 and/or the controllers 16. Otherpossible destinations include a debug monitor or window or other customoutput mechanism defined for a specific situation. The software systemdesigner, or in some cases the hardware system designer, will writetransmit stream code for each stream 28 that determines how the controlcommands are to be transferred to a given one of the control commanddestinations 16 and 34. Using the driver administrator 32, the user 24selects one or more of the control command destinations 16 and 34, and,later when run, the system 22 transfers the control commands to theselected control command destination 16 and/or 34 based on the transmitstream code in the stream 28 associated with the selected controlcommand destination 16 and/or 34.

Many control command destinations such as 16 and 34 are capable oftransmitting data back to the system 22. Data transmitted from a controlcommand destination back to the system 22 will be referred to asresponse data. The software system designer thus further writes dataresponse stream code for each of the streams 28 a, 28 b, and 28 c thatdetermines how response data is transmitted from the controllers 16 tothe system 22. The system 22 thus processes the response data sent bythe controllers 16 based on the data response stream code contained inthe streams 28.

Referring again to FIG. 1, this Figure shows that the system 22 furthercomprises a motion control component 35 and a driver stub module 36. Themotion control component module 35 is the portion of the software system22 that relates the component functions to the driver functions. Themotion control component module 35 thus contains the component code thatmakes the association between the component functions contained in theapplication program 26 and the driver functions.

The driver stub module 36 is not required to implement the basicsoftware model implemented by the system 22, but provides the system 22with significantly greater flexibility to accommodate diverse motioncontrol hardware configurations with minimal effort.

More particularly, when the driver stub module 36 is employed, thehardware designer need not develop driver code to implement all of thedriver functions; to the contrary, the hardware designer must writedriver code for implementing the core driver functions but need notwrite driver code to implement the extended driver functions. Thesoftware system designer provides the motion control driver stub 36 withstub code that identifies the combinations of core driver functions thatare employed to emulate the functionality of extended driver functions.

The motion control component 24 will determine for the selected softwaredriver 30 which extended functions, if any, the selected driver 30supports. For extended functions that are not supported, referred toherein as non-supported extended driver functions, the motion controlcomponent 35 refers to the driver stub module 36 to determine theappropriate combination of core driver functions to emulate thefunctionality of the non-supported extended driver functions. The system22 thus generates the control commands necessary to implement thenon-supported extended driver functions using the appropriatecombination of core driver functions.

The process of determining when extended driver functions need to beemulated can be optimized by providing the motion control component 35with a function pointer table that contains a pointer to each ofextended functions. When building the function pointer table, the motioncontrol component 35 checks the selected driver module 30 to see if itsupports each extended function. If the selected driver module 30supports the extended function, the motion control component module 35stores a pointer to the function, implemented by the selected drivermodule 30, in the table location corresponding to the extended function.In the event that the selected driver module 30 does not support theextended function, the motion control component module 35 stores apointer to the extended function implementation located in the driverstub module 36. The driver stub module 36 implementation of the extendedfunction contains calls to a plurality of core functions implemented bythe selected driver module 30.

Therefore, the driver stub module 36 allows the motion control systemdesigner to use, with minimal time and effort by the hardware designer,a working software driver 28 that contains driver code to implement onlythe core functions. The software driver 28 developed to implement thecore driver functions can then be improved by developing driver code toimplement extended driver functions as desired.

The use of driver code specifically designed to implement extendeddriver functions is, in general, preferable to relying on the driverstub module 36 to emulate the extended driver functions; driver codespecifically written to implement an extended driver function willalmost always obtain a more optimized implementation of the driverfunction than the emulation of that driver function with a combinationof core driver functions.

Referring again for a moment to FIG. 1, this Figure illustrates that thesystem 22 additionally comprises a driver administrator CPL applet 38and a DDE server 40. The driver administration CPL applet 38 generatesthe user interface through which the user 24 communicates with thedriver administrator module 32. The DDE server 40 provides the softwareinterface through which the application program 26 communicates with themotion control component module 35.

II. Motion Control Component

The motion control component 35 will now be described in further detailwith reference to FIGS. 2-10. The motion control component 35 is used byevery application programming the system 22 to perform motion controloperations. The major set of the API is implemented by this component.When operating, the motion control component 35 interacts with thedriver administrator 32, to get the current driver, and the driver 30and driver stub 36, to carry out motion control operations.Applications, using system 22, only interact with the motion controlcomponent 35.

This section describes the design of the motion control component 35 inthree main parts. First, all binary modules that affect the component 35are described along with their interactions with the component 35. Next,the module interaction-map is drawn in more detail to show theinteractions between all C++ objects used to implement the motioncontrol component 35. Next, the object interaction-map is tested bydisplaying the specific interactions that take place during certain, keyprocess that the component 35 is requested to perform.

The module interaction-map shown in FIG. 2 displays all binary modulesand their interactions with the motion control component 35. As can beseen from the module interaction-map, applications only communicate withthe motion control component 35. From this point, the component 35coordinates all interactions between the driver administrator 32, driver30, and driver stub 36 components.

Breaking the module interaction-map and adding the interactions takingplace between all C++ objects used to implement the motion controlcomponent 35, produces the object interaction-map shown in FIG. 3.

Each object in the diagram is described as follows. The CCmpntDispobject is the dispatch object used to dispatch exposed interfacemethods. During the dispatch process, all raw data is converted into theappropriate C++ form. For example, collections of data passed betweenOLE components is usually packaged in a raw block of memory. TheCCmpntDisp object takes care of packing outgoing data and unpackingincoming data. Data packing involves converting the data between a rawand native C++ format.

The CDriverAdmin object is used to communicate directly with the driveradministrator component. All OLE related details are encapsulated withinthis class.

The CDriverMgr object is used to control all unit mapping taking placebefore calling the appropriate Driver function. The CUnitMapper objectis used to do the actual mapping between units.

The CUnitMapper object is used to map units between the Part CoordinateSystem (PCS) and the Machine Coordinate System (MCS). Both directions ofunit mapping are done by this object.

The CDriver object is used to build the SPI table containing both coreand extended Driver functions. Depending on the level of driver support,the extended functions in the SPI table may point to functionsimplemented in either the driver stub 36 or the driver 30.

The following discussion of FIGS. 4-8 describes all main scenarios, oroperations, that occur on the motion control component 35. Eachscenario-map displays all objects involved, and the interactions thattake place between them in the sequence that they occur.

As shown in FIG. 4, before an application can use the motion controlcomponent 35, it must create an instance of the object, using theCoCreateInstance OLE function, and then initialize the instance callingthe exposed Initialize custom interface method implemented by thecomponent 35. FIG. 4 displays the sequence of events that take placewhen the Initialize method is called.

During initialization, the following steps occur. First the applicationmust create an instance of the motion control component 35 by callingthe standard OLE function CoCreateInstance. Once loaded, the applicationmust call the component 35's exposed Initialize method. When firstloaded, the component 35 loads any registration data previously stored.Next, the component 35 directs the CCmpntDisp to initialize the system.The CCmpntDisp directs the CDriverAdmin to get the current driver(s) touse. The CDriverAdmin, first, loads the driver administrator 32 usingthe standard OLE CoCreateInstance function. Next, it initializes thedriver administrator. Then, it queries the driver administrator for thedriver(s) to use and their SPI support information. Finally, the driveradministrator returns the driver(s) and the support information to thecomponent 35, and releases all interfaces used from the driveradministrator component 32.

Once receiving the active driver(s) 30 and their support information,the motion control component 35 passes the driver(s) 30 to theCDriverMgr and directs it to initialize the system. During itsinitialization, the CDriverMgr initializes the CUnitMapper. Also whileinitializing, the CDriverMgr initializes a CDriver for each driver used.After initializing each CDriver, the support information is used tobuild each SPI table inside each CDriver object. When building the SPItable, all core and supported extended SPI interfaces are queried fromthe driver. Also, when building the SPI table, the CDriver queries allinterfaces, not supported by the driver 30, from the driver stub 36.

Referring now to FIG. 5, once the motion control component 35 isinitialized, the application 26 may perform operations on it. There aretwo types of operations that may take place on the component 35:Operations that use core Driver functions, and operations that useextended Driver functions. Even though the difference between the two iscompletely invisible to the application using the component 35, theinternal interactions are different between the two. The followingdiscussion outline these differences.

The following interactions take place when the component 35 performs anoperation that uses core Driver functions only. First the applicationmust request the operation and pass all pertinent parameters to thecomponent 35. Next, the component 35 directs the CCmpntDisp to carry outthe operation. The CCmpntDisp then directs the CDriverMgr to perform theoperation and passes all pertinent parameters to it. Before carrying outthe operation, the CDriverMgr uses the CUnitMapper to convert all unitsto the Machine Coordinate System (MCS). Next, the CDriverMgr directs theCDriver object to carry out the operation and passes the newly mappedparameters to it. The CDriver object uses its internal SPI table tocommunicate directly with the core Driver function implemented by thedriver component.

FIG. 6 shows the sequence of events that occurs when the component 35 isdirected to carry out an operation that happens to use extended SPI notsupported by the driver 30. The following steps occur when the operationis requested.

First the application must request the operation and pass all pertinentparameters to the component 35. Next, the component 35 directs theCCmpntDisp to carry out the operation. The CCmpntDisp then directs theCDriverMgr to perform the operation and passes all pertinent parametersto it. Before carrying out the operation, the CDriverMgr uses theCUnitMapper to convert all units to the Machine Coordinate System (MCS).Next, the CDriverMgr directs the CDriver object to carry out theoperation and passes the newly mapped parameters to it. The CDriverobject uses its internal SPI table to communicate directly with the coreDriver function implemented by the driver component.

As briefly discussed above, when using the system 22, there are severaltypes of units and two different coordinate systems used. The process ofunit mapping involves converting measurements between the Part andMachine coordinate systems. FIG. 7 illustrates this process, and thefollowing steps occur when the operation is requested.

First the application must request the operation and pass all parametersto the component 35. Note, all parameters are in the PCS. Next, thecomponent 35 directs the CCmpntDisp to carry out the operation. TheCCmpntDisp directs the CDriverMgr to carry out the operation and passesthe PCS parameters to it. The CDriverMgr takes all measurements and usesthe CUnitMapper to convert them to the MCS. The newly mapped parametersare then passed to the Cdriver. The CDriver directs either the driver orthe driver stub component to carry out the operation.

When the application is finished using the motion control component 35it directs the component 35 to free all of its resources by calling itsexposed Release method. This process is depicted in FIG. 8. During theclean-up process, the following steps occur.

First the application must direct the component 35 to release all of itsresources by calling its Release method. When invoked, the component 35passes the call on to the CCmpntDisp object. The CCmpntDisp objectdirects the CDriverMgr to release any resources it is using. TheCDriverMgr directs each CDriver object to release any of its resources,then deletes the CDriver objects. First, the CDriver object releases anyinterfaces it is using from the driver component. Then, the CDriverobject releases any interfaces it is using from the driver stubcomponent.

FIG. 9 is an interface map related to the motion control component 35.FIG. 10 is a data map showing how data relating to the whether extendeddriver functions need to be emulated is stored. Attached hereto asAppendix C is a document that describes the actual OLE Interfacesexposed, the definitions of the data structures used when passing dataaround, and the definitions of each class used internally by the motioncontrol component 35.

III. Software Drivers

The driver 30 is used by both the driver administrator 32 and thecomponent 35. Its main purpose is to implement functionality thatgenerates motion control commands for the specific hardware supported.For example, the AT6400 driver, used to control the Compumotor AT6400motion control hardware, generates AT6400 command codes. During theinitialization phase of the system 22, the driver administrator 32communicates with each driver 30, allowing the user to add, remove, orchange the configuration of the driver. When an application, using thesystem 22, is run, the component 35 communicates with the driver 30directing it to carry out the appropriate motion control operations.

This section describes the complete design of a generic driver 30. Alldrivers are designed from the base design described in this manual. Thissection is divided into three parts. First, a module interaction-mapthat describes all binary modules that interact with the driver 30 isdiscussed. Next, the module interaction-map is drawn as an objectinteraction-map, where all the internals of the driver are exposed. Inthis map, all C++ objects, making up the driver, and their interactionsare shown. Next, several scenario-maps are drawn. Each scenario-mapdisplays the interactions taking place between the C++ objects involvedduring a certain process. Finally, this section describes the interfacesexposed by the driver component, all data structures used, and thedefinitions of each C++ class used.

Referring now to FIG. 11, the module interaction-map displays all binarymodules and their interactions with the driver 30. There are two modulesthat interact directly with the driver: the motion control component 35,and the driver administrator 32. The driver administrator 32 queries andchanges the driver settings and the component 35 directs the driver tocarry out motion control operations, such as moving to a certainlocation in the system. Shown at 42 in FIG. 11 is the standard Windowsregistration database, referred to herein as the registry.

Breaking the module interaction-map down into more detail by includingthe interactions taking place between all C++ objects used to implementthe driver, produces the object interaction-map. The objectinteraction-map for the driver 30 is shown in FIG. 12.

Each object in the diagram is described as follows.

CDriverDisp is the dispatch object used to dispatch exposed interfacemethods. During the dispatch process, all raw data is converted into theappropriate C++ form. For example, collections of data passed betweenOLE components is usually packaged in a raw block of memory. TheCDriverDisp object takes care of packing outgoing data and unpackingincoming data. Data packing involves converting the data between a rawand native C++ format.

The CStreamMgr object is responsible for managing the set of streamsregistered with the driver. Streams, may be added, removed, and enabled.Only enabled streams are sent data. The CLSID and enabled status of eachstream registered, is stored in the registration database. Whencommunicating to streams, the CStreamMgr is used to send the commandstring to all enabled streams.

The CCommandMgr object is used to build commands sent to the stream, andextracting responses received from the stream. The CCommandMgr is thecontrolling object that manages the CResponse, CCommandList, and CStreamobjects.

The CCommandList object stores the complete list of commands making upthe motion control command language. Such commands may be stored as textresources or in a text file.

The CCommand object builds command strings that are then sent to theCStream. Each command built is a complete motion control command string.

The CResponseList object builds CResponse objects that are initializedwith the parsing format for the expected response.

The CResponse object converts raw response strings, returned by theCStream, and converts them into C++ data types. For example, a responsestring containing position data may be converted into a set of doublevalues.

The CStream object is used to communicate directly with the underlyingstream component.

FIGS. 14-20 contain scenario maps that describe all main scenarios, oroperations, that occur on the driver 30. Each scenario-map displays allobjects involved, and the interactions that take place between them inthe sequence that they occur.

There are two types of operations that occur on the driver 30. First,the driver administrator 32 may initiate operations, such as addingstreams or configuring the driver. Next, the motion control component 35may initiate operations on the driver when an application is actuallyrunning. The following discussion describes each perspective, startingwith the operations directed by the Driver Administrator; all operationsmade on the driver by the driver administrator are discussed in theorder that they may occur when using the driver.

Before a driver may be used, it must be registered in the OLE system. Inorder to register a driver the driver administrator first verifies thatthe module being registered is actually an driver 30, then it calls theDLLRegisterServer exported function to register the driver. Each moduleof the system 22 exports a function called DLLGetModuleType. Thisfunction is used to verify that the module is an driver 30 component.FIG. 13 displays the interactions that take place when registering adriver.

During the registration process shown in FIG. 13, the following stepsoccur. First, the driver administrator must load the DLL, containing thestream component, verify that the module is an driver 30. To do so, thedriver administrator calls the DLLGetModuleType function, exported bythe driver. If the function returns a value that contains the valueXMC_DRIVER_MT in the high byte, then the driver administrator proceedsand registers the driver by calling its exported function,DLLRegisterServer. When called, the implementation of theDLLRegisterServer writes all OLE 2.0 registration information to theWindows registration database.

Referring now to FIG. 14, after the driver is registered, the driveradministrator can load the component 35 using the OLE CoCreateInstancefunction. During the initialization process, the driver loads allregistration data and initializes both the CDriverDisp and CStreamMgrC++ objects.

During initialization, the following steps occur.

Before loading the driver component, the driver administrator must querythe driver module for its CLSID. Calling the driver's exported function,DLLGetCLSID, returns the CLSID. Once it has the CLSID, the driveradministrator may create an instance of the driver by calling thestandard OLE function CoCreateInstance. When first loaded, the driverloads any registration data previously stored. Next, the driver directsthe CDriverDisp object to initialize the system. When notified, theCDriverDisp object initializes itself and then directs the CStreamMgr toinitialize itself. During its initialization, the CStreamMgr loads allstream settings from the registration database. For example, the CLSIDand enabled state of all streams previously registered with the driver,are loaded.

After initializing the driver, the driver administrator may performoperations on it. For example, the driver administrator may request thedriver to add or remove a stream. FIG. 15 displays the sequence ofevents occurring when the driver is requested to add a new stream. Whenadding a stream, the following steps occur.

First the driver administrator directs the stream to add a new streamand passes CLSID of the stream, to be added, to the driver. The driverthen passes the CLSID to the CDriverDisp object and directs it to addthe stream. The CDriverDisp object passes the information on to theCStreamMgr and directs it to add the stream. In the final step, theCStreamMgr assumes that the module is a valid stream component 28 andadds the CLSID to the drivers set of information in the registrationdatabase.

Another operation requested of the driver, after initialization, is thatof querying it for its current settings. Before displaying informationabout the driver, like the name of the hardware it supports, the driveradministrator must query the driver for the information. For example,FIG. 16 displays the process of querying the driver for an enumerationof the streams registered with it. When querying the driver forinformation, the following steps occur.

First the driver administrator, calls the interface method used to querythe driver's stream enumeration. Next, the driver directs theCDriverDisp to create the stream enumeration. The CDriverDisp objectthen directs the CStreamMgr to prepare the stream enumeration. TheCStreamMgr checks the registration database and makes sure its internalstate is in sync with the data stored in the registry. Next, it sets alock that will cause all stream management operations, such as adding orremoving streams, to fail. The CStreamMgr prepares the list of streamsand loads them into memory using the CStream object. The CStream objectloads the stream component using the OLE CoCreateInstance API.

After the driver administrator is done using the driver, it must releasethe driver by calling its exposed Release method. Calling this method,directs the driver to release all resources used. FIG. 17 displays theprocess of releasing the driver component. During the clean-up process,the following steps occur.

First the driver administrator must direct the driver component to cleanitself up by calling its Release method. When invoked, the drivercomponent passes the call on to the CDriverDisp object. The CDriverDispobject then directs the CStreamMgr to save all data. The CStreamMgrsaves all data, including the state of each stream, in the registrationdatabase. Finally, the driver saves all internal data in theregistration database.

After a driver is successfully installed into the system 22 andconfigured using the driver administrator, it is ready for use by themotion control component 35. The component 35 uses the driver 30 whenperforming motion control operations requested from the applicationusing the component 35. The following discussion describes the component35 directed operations that can take place on the driver.

Before using the driver, it must be initialized by the component 35.This operation is different from the driver initialization taking placeon the driver when used by the driver administrator because the systemmust be prepared for sending and receiving commands. In order to preparefor the data communication, the stream must be initialized and thenopened. FIG. 18 describes the initialization process. The followingsteps occur during the initialization process.

First the component 35 must direct the driver to initialize itself. Thisis usually a two step process. In the first step, the component 35creates and instance of the driver using the standard OLECoCreateInstance function. Next, the Initialize method, exposed by thedriver, is called to prepare the driver for data transmissions. When theInitialize method is called, the driver first loads any internal datastored in the registration database 42. Next, the driver directs theCDriverDisp to initialize the internal system. The CDriverDisp thendirects the CStreamMgr to initialize the streams. Next, the CStreamMgrloads all data from the registration database, including the set of allCLSID's and enabled status' for all streams registered with the driver.Then the CStreamMgr loads each enabled stream by creating a new CStreamobject for each enabled stream. When creating each CStream object, theCLSID for the underlying stream is passed to the CStream object. Wheneach CStream object is created and attached to a stream component itloads the component 35 by calling the standard OLE CoCreateInstancefunction. Once the CStreamMgr is done, the CDriverDisp directs theCCommandMgr to initialize itself. During its initialization process, theCCommandMgr initializes and loads the CCommandList. Also, when theCCommandMgr is initializing, it loads the CResponseList corresponding tothe CCommandList.

Once the system is initialized, the motion control component 35 candirect the driver to carry out certain command operations. Commandoperations are standard motion control operations such as moving to aspecific location in the system, or querying the system for the currentposition. FIG. 19 describes the process of commanding the driver tocarry out a certain operation. When commanding the driver to perform acertain operation the following steps occur.

First, the component 35 directs the driver to perform the operation,such as moving to a position or querying the system for the currentposition. Next, the driver directs the CDriverDisp object to perform theoperation. The CDriverDisp object then directs the CCommandMgr to buildthe appropriate command. Any parameters related to the command arepassed to the CCommandMgr. For example, when directing the driver tomove to a certain position, the position information is passed to theCCommandMgr. Next, the CCommandMgr requests the CResponseList to createa CResponse object. The CResponseList looks up the response format anduses it to create a new CResponse object that is returned to theCCommandMgr. Then, the CCommandMgr directs the CCommandList to createthe command. Any parameters related to the command are passed to theCCommandList. The CCommandList creates a new CCommand object, looks upthe raw command string, and passes it and the command parameters to theCCommand object who then builds the command string.

The CCommandMgr, then passes the CCommand object, returned by theCCommandList, and the previously created CResponse object to theCStreamMgr object. The CStreamMgr object is directed to process theobjects. The CStreamMgr passes the CCommand and CResponse objects to allenabled CStream objects. The CStream object queries the CCommand objectfor the full command string in raw text form. The raw text command ispassed to the stream component. Next, the CStream object waits for theresponse, then reads the raw text response into a buffer. The raw textresponse is then passed to the CResponse object. Next the CRETONNEobject is returned to the CStreamMgr, who returns it to the CCommandMgr,who returns it to the CDriverDisp object. Eventually the CResponsereturns to the CDriverDisp object, who then directs the CResponse toconvert the response into a generic C++ type. The generic type isreturned to the motion control component 35.

Once the component 35 is finished using the driver, the driver must bereleased by calling its Release method. Releasing the driver frees allresources used by the driver. FIG. 20 describes the process of releasingthe driver. The following steps occur when cleaning up and freeing allresources used by the driver.

First, the component 35 must call the driver's Release method. Whencalled, the driver directs the CDriverDisp object to release anyresources used. The CDriverDisp then directs the CStreamMgr to free anyresources used. The CStreamMgr then frees all active CStream objects.Each CStream object releases all stream component interfaces used. Nextthe CDriverDisp directs the CCommandMgr to free all of its resources.During its clean-up, the CCommandMgr frees the CCommandList object. Tocomplete its clean-up, the CCommandMgr frees the CResponseList object.

Attached hereto as Appendix D is a document that describes the actualOLE Interfaces exposed, the definitions of the data structures used whenpassing data around, and the definitions of each class used internallyby the driver.

IV. Streams

This section describes the stream component 28 used as the datatransport layer between the driver 30 component and the destinationoutput location such as the motion control device 20 and/or the outputfile 34. For example, when using motion control hardware that isconnected to the PC Bus, the driver 30 Component will communicate withthe PC Bus stream component 28.

The design of a stream component 28 will be discussed in three parts.First, a Module Interaction-Map describes the modules that are involved,with respect to the stream, and how they interact with one another.Next, the Object Interaction-Map breaks the Module Interaction-Map downinto a more detailed view that not only displays the interactionsoccurring between modules, but also the interactions taking placebetween the C++ objects within the stream component 28. Then, the ObjectInteraction-Map is “tested” by running it through several Scenario-Maps.Each Scenario-Map displays the object interactions taking place during acertain operation.

The Module Interaction-Map shown in FIG. 22 displays all modules thatinteract with the stream component 28. Interactions begin from twodifferent perspectives. First, the driver administrator 32 interactswith the stream component 28 when installing, removing, and configuringthe stream. Next, when used, each driver 30 interacts with the streamwhile sending and retrieving data to and from the destination. Forexample, when a driver writes data to a text file stream, the streamtakes care of writing the data out to the file. Or, if the driver readsdata from a PC Bus stream, the stream does the actual read from thehardware and passes the data back to the driver.

Drivers only communicate with streams that have been specificallyconnected to the driver. Once connected, the stream is used tocommunicate with the destination object, like the PC Bus, serial I/Oconnection, text file, or debug monitor.

The stream component 28 shown in FIG. 22 is the object that operates asthe data transport layer for each driver. Each stream has a differenttarget that defines the type of the stream. The following are thecurrent stream targets.

-   -   PC Bus/WinNT—This Windows NT stream uses a Windows NT SYS device        driver to communicate directly with the motion control hardware        connected to the PC Bus.    -   PC Bus/Win95—This Windows 95 stream uses a Windows 95 VxD to        communicate directly with the motion control hardware connected        to the PC Bus.    -   PC Bus/Win 3.1—This Windows 3.1 stream communicates directly        with the motion control hardware connected to the PC Bus.    -   Serial—This stream uses the COMM API to communicate with the        motion control hardware connected to the serial port.    -   Text File—This stream is write-only and sends all data to a text        file.    -   Debug Monitor—This stream is write only and sends all data to        the debug monitor.    -   Custom—This is a custom stream that sends data to an unknown        location.

Similar to the Module Interaction-Map, the Object Interaction-Mapdisplays interactions between modules. In addition, this map, shows allinteractions taking place between each C++ object within the streamcomponent 28. FIG. 23 is the Object Interaction-Map for the streamcomponent 28.

Each object in the diagram is described as follows. The CStreamDispobject is the dispatch object used to dispatch exposed interfacemethods. During the dispatch process, all raw data is converted into theappropriate C++ form. For example, collections of data passed betweenOLE components is usually packaged in a raw block of memory. TheCStreamDisp object takes care of packing outgoing data and unpackingincoming data. Data packing involves converting the data between a rawand native C++ format.

The CRegistryMgr object takes care of managing all data stored in theregistration database. Since many streams of the same type may exist atthe same time, each stream is assigned a handle. The handle assigned, isused by the stream to look up the location it uses to load and storedata in the registration database, much as an library index is used tolocate a library book.

All input and output is funnelled through the CIOMgr manager. Managementof input and output operations consists of buffering data andcontrolling primitives used to transport data to and from the targetlocation.

The CIOHAL object is the input/output hardware abstraction layer. Within this object lay all hardware dependent code such as calls to inp andoutp. Each different type of stream contains a different implementationof this object.

Scenario-Maps are specialized Object Interaction-Maps that display howeach module and the objects inside the stream component interact withone another during the operation described by the map. The Scenario-Mapsin FIGS. 24-32 are broken into two different categories; those that areinitiated by the driver administrator 32, and those that are initiatedby the driver 30.

Operations directed by the driver administrator are usually related toinitializing, uninitializing, and configuring the stream. The followingsections describe all operations, directed by the driver administrator,that take place on the stream.

Before a stream component can be used by anyone, it must be registeredin the Windows registration database. Registration is a standard OLE 2.0operation required in order to use any OLE 2.0 component, such as thestream component. FIG. 24 describes this process. During theregistration process, the following steps occur.

First, the driver administrator must load the DLL, containing the streamcomponent, verify that the module is an stream component 28. To do so,the driver administrator calls the DLLGetModuleType function, exportedby the stream. If the high byte in the return value contains the valueXMC_STREAM_MT, then the driver administrator proceeds and registers thestream by calling its exported function, DLLRegisterServer. When called,the implementation of the DLLRegisterServer writes all OLE 2.0registration information to the Windows registration database.

After the stream component is successfully registered, it is ready forinitialization. During initialization, the stream component not onlyinitializes itself, but also initializes any device drivers used byregistering the driver with the operating system. For example, theWindows NT stream component registers the Windows NT SYS driver withWindows NT and starts the service. FIG. 25 describes this process.During initialization, the following steps occur.

First the driver administrator must direct the stream to initializeitself. When making this call, the name and location of the driver used,and the handle of the stream are passed into the method as arguments.Once directed to initialize itself, the stream component calls theCStreamDisp and directs it to initialize the system. The CStreamDispobject then directs the CRegistryMgr to load all pertinent data for thestream using the handle passed to it. The CRegistryMgr loads all datafrom the registration database. After all information is loaded from theregistry, the CStreamDisp directs the CIOMgr to register the appropriatedriver with the operating system. The CIOMgr directs the CIOHAL toregister the driver, if appropriate. If running in Windows NT, theCIOHAL registers the SYS driver with the Windows NT operating system andstarts the driver. If running in Windows 95, the VxD integrity isverified with a quick, dynamic, load and unload.

After initializing the stream component, it may be queried for itscurrent settings or directed to set new settings. Since both operationsare very similar, only changing settings will be described. Streamsettings include data such as: port addresses, IRQ levels, file names,etc. Any data needed to communicate with the output/input target areincluded in the stream settings. FIG. 26 describes the process ofchanging the streams settings. During the setup process, the followingsteps occur.

First the driver administrator directs the stream to use the data passedto change its internal data. Once directed, the stream component passesthe interface method invocation to the CStreamDisp object. TheCStreamDisp object then directs the CRegistryMgr to store the newsettings. The CRegistryMgr stores the new values in the registrationdatabase.

When the driver administrator is done using a stream component, it mustclean up the resources used. FIG. 27 describes this process. During theclean-up process, the following steps occur. First the driveradministrator must direct the stream component to clean itself up bycalling its Release method. When invoked, the stream component passesthe call on to the CStreamDisp object. The CStreamDisp object thendirects the CRegistryMgr to save all data. All persistent data is savedto the registration database by the CRegistryMgr.

Driver directed operations occur when each driver 30 uses the streamcomponent 28 connected to it. Remember, each stream component is used asthe data transport layer. Each driver uses the stream to transfer themotion control command data, it generates, to the output target. Streamsare also used to transfer data back to the driver when read operationsoccur. Only certain streams are readable.

Before the driver can perform operations on the stream, the stream mustbe initialized. Initialization occurs in two steps. First the OLE streamcomponent must be loaded, and then once it is, the stream must beexplicitly initialized. FIG. 28 describes the second portion of theinitialization process. The following steps occur during theinitialization process.

First the driver must invoke the Initialize methods exported by one ofthe stream interfaces. When calling Initialize, the driver passes to thestream, the stream handle. Next, the stream passes the directive on tothe CStreamDisp object for dispatching. The CStreamDisp object firstdirects the CRegistryMgr to load all settings stored in the locationdefined by the stream handle. The CRegistryMgr reads in the data storedin the registry at the handle. After the data is loaded, theCStreamDisp, directs the CIOMgr to initialize itself. As part of itsinitialization, the CIOMgr initializes the CIOHAL object that it isusing.

Once a stream has been initialized, it must be opened. Opening a streamplaces the stream in a state where it can pass data between the driverand the target. FIG. 29 describes the process of opening a stream. Whenopening a stream, the following steps occur.

First the driver directs the stream to open itself, by calling the Openexposed interface method. Once directed, the stream passes the call onto the CStreamDisp object. Next, the CStreamDisp object directs theCIOMgr to open the stream. At this time, the CIOMgr prepares any buffersthat will later be used when transferring data through the stream. Afterthe buffers are ready, the CIOMgr directs the CIOHAL object to interactwith the target and open it. CIOHAL directly communicates with thetarget or with a device driver and opens the stream. When operating withhardware streams, the device driver, or Serial IO directly communicateswith the hardware and prepares it for operation.

After opening a stream, it is ready to perform data transportoperations. There are two main data transport operations available:Reading data, and writing data. FIG. 30 describes the process of writingdata to the stream. When writing to the stream, the following stepsoccur. First the driver directs the stream to write data to the targetand passes the data to the stream. Next, the stream passes the data tothe CStreamDisp object. The CStreamDisp object passes the block of datato the CIOMgr and directs it to write it to the target. The CIOMgrobject either passes the complete block of data to the CIOHAL object, orstores the block in an internal buffer and then passes pieces of thebuffer to the CIOHAL object until the complete buffer is sent. TheCIOHAL object takes the data passed to it and either sends it directlyto the target, passes it to a device driver, or calls COMM API to sendthe data to the Serial IO port. The device driver or COMM API sends thedata directly to the hardware controlled.

Certain streams, like the PC Bus and Serial IO streams, return dataafter write operations occur on them. The data returned may be specificto a previous request for data, or status describing the success orfailure of the previous write operation. FIG. 31 describes the processof reading data from the stream. It should be noted that not all streamsare readable. Currently, the only readable streams are the PC Bus andSerial streams. During the operation of reading data from the target,the following steps occur.

First the driver directs the stream to read data from the target. Thestream passes the call on to the CStreamDisp object. The CStreamDispobject directs the CIOMgr to perform the read. Depending on how thestream is implemented, the CIOMgr may either make one call or multiplecalls to the CIOHAL object. If multiple calls are made, all data read isstored in CIOMgr internal buffers. The CIOHAL object either directlycommunicates to the hardware, uses the COMM API, or a device driver toread the data. If a device driver or the COMM API are used, theydirectly communicate with the hardware to read the data.

Once the driver is done using the stream, it must direct the stream toclean-up all resources used. To do so, the driver calls the standardRelease method. FIG. 32 displays the sequence of events taking placeafter the Release method is called. The following steps occur whencleaning up and freeing all resources used by the stream.

First the driver must call the stream's Release method. Next, the streamdirects the CStreamDisp object to release all resources used. TheCStreamDisp object then directs the CIOMgr to free any resources used inbuffers, etc. Next, the CIOMgr directs the CIOHAL to free any resourcesused. During its clean-up and depending on the type of stream, theCIOHAL will delete text files used, close the debug monitor, shut-downthe hardware, or direct any device drivers to shut-down the hardware. Ifdevice drivers or the COMM API are used, they direct the hardware toshut-down.

FIG. 33 depicts an interface map for the stream 28. Attached hereto inAppendix E is a document that describes the actual OLE Interfacesexposed, the definitions of the data structures used when passing dataaround, and the definitions of each class used internally by the stream.

V. Driver Stub Module

The driver stub module 36 is used to fill in the extended Driverfunctions that the driver 30 is unable to support or implement. Bysimulating the extended SPI, applications are able to use a larger setof motion control functionality than would be available if theapplication directly programmed the motion control hardware. In order toimplement the extended SPI, the driver stub uses software algorithmsthat call core SPI interface methods implemented by the driver 30.During the initialization of the driver stub, the driver 30 to use isregistered with the driver stub.

This section describes all aspects of the driver stub 36 in three basicparts. The first part of this section describes all binary modulesaffecting the driver stub. Next, a more detailed view, that includes allC++ objects used inside the driver stub, is described. Then severalprocesses that take place on the driver stub are described.

The module interaction-map displays all binary modules and theirinteractions with the driver stub 36. As can be seen from FIG. 34, thedriver stub is used by the component 35. More or less, the driver stubacts as a helper to the component 35 by filling in all extended Driverfunctionality possible.

By taking the module interaction-map in FIG. 34 and displaying allinteractions taking place with all C++ objects implementing the driverstub, we produce what is called the object interaction-map. FIG. 35 isthe object interaction-map for the driver stub 36 component.

Each object in the diagram is described as follows.

-   -   The CDriverStubDisp object is the dispatch object used to        dispatch exposed interface methods. During the dispatch process,        all raw data is converted into the appropriate C++ form. For        example, collections of data passed between OLE components is        usually packaged in a raw block of memory. The CDriverStubDisp        object takes care of packing outgoing data and unpacking        incoming data. Data packing involves converting the data between        a raw and native C++ format.    -   The CSPIMgr object is responsible for managing all SPI issues        such as managing the CSimpleDriver by directing it to connect to        the appropriate SPI core interfaces exposed by the driver.    -   The CSimpleDriver object is used to directly communicate with        the driver implementing the SPI core interfaces. The        CSimpleDriver only communicates with the core SPI interfaces        implemented by the driver.

The following discussion describes all main scenarios, or operations,that occur on the driver stub 36. Each scenario-map displays all objectsinvolved, and the interactions that take place between them in thesequence that they occur. All operations on the driver stub originatefrom the motion control component 35. In addition to the motion controlcomponent 35, the XMC Setup Component interacts with the driver stubwhen installing the system 22. It should be noted that all scenariosbelow assume that the driver stub 36 has already been registered in theOLE system. Registering this component is the responsibility of thesetup application and setup component.

This discussion describes all operations made on the driver stub by themotion control component 35. Each section is discussed in the order thatthey may occur when using the driver.

As shown in FIG. 36, before using the driver stub 36, the motion controlcomponent 35 must initialize it by creating an instance of the driverstub, and then initializing the instance created. Calling the standardOLE function CoCreateInstance completes the first step. After aninstance is created, the component 35 must call the driver stub exposedInitialize interface method. During initialization, the following stepsoccur.

The component creates an instance of the driver stub by calling thestandard OLE function CoCreateInstance. Once loaded, the CLSID of thedriver to use is passed to the driver stub when calling its Initializeexposed interface method. When first loaded, the driver loads anyregistration data previously stored. Next, the component 35 passes theCLSID, of the driver to use, to the CDriverStubDisp object and directsit to initialize the system. The CDriverStubDisp object then directs theCSPIMgr to initialize itself and passes the driver CLSID to it. TheCSPIMgr passes the CLSID to the CSimpleDriver and directs it to onlyquery the core SPI interfaces exposed by the driver. The CSimpleDriverloads an instance of the driver then queries all core interfaces exposedby the driver.

Once the driver stub is initialized, it is ready to perform operationssuch as performing extended Driver functions. FIG. 37 describes thesteps that occur when the component 35 directs the driver stub toperform an extended SPI operation. The following steps occur when theoperation is requested.

First the component 35 must request the operation and pass all pertinentparameters to the driver stub. Next, the driver stub directs theCDriverStubDisp to handle the operation. The CDriverStubDisp thendirects the CSPIMgr to perform the SPI extended function and passes theappropriate XMC_EXT_SPI identifier as a parameter. The CSPIMgr calls theappropriate function corresponding to the XMC_EXT_SPI identifier. Thefunction simulates the extended Driver function and calls theCSimpleDriver for core operations. When directed, the CSimpleDriverperforms SPI core functions by directly calling the exposed interfacesimplemented by the driver.

When the motion control component 35 is finished using the driver stub36, it must release it by calling the exposed Release method. Callingthe Release method causes the driver stub to free all the resources ituses. FIG. 38 displays this sequence of events. During the clean-upprocess, the following steps occur.

First the component 35 must direct the driver stub to release all of itsresources by calling its Release method. When invoked, the drivercomponent passes the call on to the CDriverStubDisp object. TheCDriverStubDisp object then directs the CSPIMgr to release any resourcesthat it was using. The CSPIMgr releases all resources including theCSimpleDriver object used. When freed, the CSimpleDriver releases anyinterfaces used from the driver.

FIG. 39 is an interface map of the driver stub module 36. Attachedhereto as Appendix F is a document that describes the actual OLEInterfaces exposed, the definitions of the data structures used whenpassing data around, and the definitions of each class used internallyby the driver.

VI. Driver Administrator Module

The driver administrator 32 is used from two different perspectives.When the driver administrator Control Panel Applet 38 is used toconfigure the system, the applet directs the driver administrator 32 tocarry out the operations. The applet 38 simply provides theuser-interface, and the component 35 does the real work of managingdrivers and streams used with the system 22. Using the driveradministrator component with the control panel applet is the firstperspective on using the component 35.

In the second perspective, the motion control component 35 uses thedriver administrator component to query for the current set of enabledthe driver 30. It should be noted that, currently, only single driveroperation is allowed. Clearly, the system 22 may support multipledrivers that are virtualized. For example, if two, four axis, driversare installed, applications using the system could act as though theywere using an eight axis system.

This section describes the driver administrator 32 in three main parts.First, all modules interacting with the driver administrator componentare described along with their interactions. Next, the moduleinteraction-map is expanded to display all interactions taking placebetween the C++ objects used to implement the driver administrator 32Component. This description is called the object interaction-map. Then,the object interaction-map is tested by running it through severalscenarios, or scenario-maps. Each scenario-map displays the events andthe order in which they occur in a certain process taking place on thedriver administrator component.

The module interaction-map shown in FIG. 40 displays all binary modulesand their interactions with the driver administrator 32 Component. Boththe driver administrator CPL 38 and the motion control component 35 arethe main modules that interact with the driver administrator 32Component.

The driver administrator CPL module 38 provides the user-interface thatallows the user to add, configure, and remove drivers and streams in thesystem 22. The driver administrator 32 handles all driver and streammanagement. Even though the control panel applet provides theuser-interface, this module 32 does the actual management work.

In addition, the driver administrator is used by the component 35 toaccess the current driver(s) to use when carrying out motion controloperations. For example, if the AT6400 driver is selected as the currentdriver when the component 35 queries the driver administrator, thedriver administrator returns the CLSID of the AT6400 driver.

Taking the driver administrator 32, displayed in the moduleinteraction-map, and displaying all interactions occurring between theC++ objects used to implement the administrator 34, produces the objectinteraction-map therefor. The object interaction-map for the driveradministrator 32 is shown in FIG. 41.

Each object in the diagram is described as follows.

The CDriverAdminDisp object is the dispatch object used to dispatchexposed interface methods. During the dispatch process, all raw data isconverted into the appropriate C++ form. For example, collections ofdata passed between OLE components is usually packaged in a raw block ofmemory. standard OLE function CoCreateInstance. Next, the exposedInitialize interface method must be called. When the Initialize methodis called, the driver administrator component directs theCDriverAdminDisp to initialize the system. Next, the CDriverAdminDispdirects the CModuleMgr to initialize itself and any modules that it ismanaging. The CModuleMgr, first, loads all information from theregistration database. Then for each driver registered, the CModuleMgrcreates an instance of the driver by calling the standard OLE functionCoCreateInstance. Next, the CModuleMgr calls each drivers Initializemethod, passing to the method the CLSID of the driver component toattach. The CSimpleDriver attaches to the driver component by callingthe standard OLE function CoCreateInstance.

The driver administrator 32 can register both drivers and streams.Registering drivers is very direct, since the driver administratormanages the drivers registered in the system. Registering streams, onthe other hand, is more complex, since each stream must be registeredwith a driver and the driver manages the streams registered with it, notthe driver administrator. The following discussion describes the processof registering both drivers and streams.

Registering a driver entails verifying that the module is actually adriver, verifying that the driver can be loaded, and storing the driverinformation in a persistent location. FIG. 43 describes this process.When registering a driver, the following steps occur.

First, the driver administrator CPL passes the name of the driver anddirects the driver administrator component to register it. Next, thedriver administrator component passes the driver name to theCDriverAdminDisp and directs it to register the module. TheCDriverAdminDisp directs the CModuleMgr to register the new driver. TheCModuleMgr creates a new CSimpleDriver and requests it to register thedriver. First the CSimpleDriver verifies that the driver is valid bycalling its DLLGetModuleType exported function. If the function returnsXMC_DRIVER_MT the CSimpleDriver then calls the driver's exportedfunction DLLRegisterServer to register the module in the OLE system.Next the CLSID is queried from the module by calling its exportedDLLGetCLSID function. The CLSID returned is then used to load the driverby calling the standard OLE function CoCreateInstance. If theCSimpleDriver is successful, the CModuleMgr stores the driver CLSID inthe registration database.

Registering a stream is similar to registering a driver, but a littlemore complex, since each stream must be registered with a specificdriver. FIG. 44 displays the process of registering a stream. Whenregistering a stream, the following steps occur.

First, the driver administrator CPL passes the CLSID of the driver andthe filename of the stream to register with the driver, to the driveradministrator component. The driver administrator component directs theCDriverAdminDisp to register the stream. The CDriverAdminDisp objectdirects the CModuleMgr to register the stream and passes the CLSID ofthe driver and the name of the stream along to it. First, the CModuleMgrverifies that the CLSID of the driver one of the registered drivers. Ifit is not, the driver is registered as discussed above.

Next, the CModuleMgr creates a new CSimpleStream object and directs itto verify and load the stream component. The CSimpleStream firstverifies that the module is actually an stream component 28 by callingits exported DLLGetModuleType function. If the function returnsXMC_STREAM_MT, the CSimpleStream continues and registers the streamcomponent by calling its DLLRegisterServer exported function. Finally,the CSimpleStream object queries the new module for its CLSID by callingthe module's exported DLLGetCLSID function. The new CLSID is used, bythe CSimpleStream, to load the stream component using the standard OLEfunction CoCreateInstance. If the CSimpleStream succeeds, the CLSID ofthe stream is passed along to the CSimpleDriver who is directed toregister the stream. The CSimpleDriver passes the CLSID to the drivercomponent and directs it to register the stream.

The following discussion describes setting information in either adriver or stream. When the user edits information in the driveradministrator control panel applet 38, the applet 38 directs the driveradministrator 32 to edit the settings for the stream or driver beingedited. The following discussion describes how this configurationprocess works.

Editing the settings of a driver takes place when the user changes thedriver settings displayed in the driver administrator CPL. Changingthese settings causes the process described in FIG. 45 to occur withinthe driver administrator component. The following steps occur whensetting the driver configuration.

When driver settings are changed in the CPL 38, the driver administratorCPL directs the driver administrator component to make the appropriatechanges to the driver corresponding to the driver handle. AXMC_DRIVER_INFO structure is passed to the component 35, describing thenew values for the driver. The driver administrator component takes theXMC_DRIVER_INFO structure and the handle to the driver and passes theinformation to the CDriverAdminDisp object, directing it to change thesettings in the driver. The CDriverAdminDisp object directs theCModuleMgr to edit the driver corresponding to the driver handle. TheCModuleMgr locates the CSimpleDriver with the handle and directs it tochange its settings to those stored in the XMC_DRIVER_INFO structure.The CSimpleDriver passes the XMC_DRIVER_INFO structure to the drivercomponent and directs it to change its settings.

As shown in FIG. 46, when the user edits stream settings in the driveradministrator CPL 38, the following steps occur.

After the user changes settings for the stream in the CPL, the driveradministrator CPL directs the driver administrator component to changethe stream's settings and passes a handle to the driver containing thestream, a handle to the stream, and a XMC_STREAM_INFO structuredescribing the new values. The driver administrator component directsthe CDriverAdminDisp object to change the streams settings. TheCDriverAdminDisp object directs the CModuleMgr to change the settings ofthe stream corresponding to the handle.

First, the CModuleMgr locates the driver corresponding to the driverhandle. Next, it requests the CSimpleDriver to change the settings forthe stream corresponding to the stream handle. The CSimpleDriversearches for the stream corresponding to the stream handle and directsit to change its settings to those stored in the XMC_STREAM_INFOstructure. The CSimpleStream directly communicates with the streamcomponent and directs it to change its settings to those in theXMC_STREAM_INFO structure.

There are two different types of information that may be queried fromthe driver administrator 32: the enumeration of all drivers registered,and the driver information map. The motion control component 35 uses thedriver enumeration when selecting the set of drivers to use and controlduring motion control operations. The driver information map, on theother hand, is used by the driver administrator CPL 38 to update theuser-interface display describing all drivers and streams registered inthe system. The following discussion describes the process of queryingfor both the driver enumeration and the driver information map. Queryingfor the driver enumeration occurs during the initialization of themotion control component 35. When initializing, the component 35 mustknow what drivers to use when performing motion control operations. Thedriver administrator 32 Component is used for that very purpose.Querying the driver enumeration just returns a pointer to theIXMC_EnumDriver interface exposed by the driver administrator 32Component. FIG. 47 displays the events that occur when using theinterface to get each driver in the enumeration. Using the interfacecauses, the following steps occur.

First, the motion control component 35 queries the driver administrator32 Component for the next driver. Next, the driver administrator 32Component directs the CDriverAdminDisp to get the next driver supported.The CDriverAdminDisp directs the CModuleMgr to get the next driver. TheCModuleMgr then directs the CSimpleDriver to either return the CLSID ora pointer to the IUnknown interface for the driver, depending on theparameters of the enumeration. If the CSimpleDriver is requested toreturn a pointer to the IUnknown interface, the interface is queriedfrom the driver component.

Another set of information that may be queried from the driveradministrator 32 consists of the driver information map. This data isused by the driver administrator CPL 38 when displaying informationdescribing the drivers and streams registered in the system. As shown inFIG. 48, when querying the system for the driver interface map, thefollowing steps occur.

First, the driver administrator CPL 38 queries the driver administrator32 Component for the current driver information map. When queried, thedriver administrator component directs the CDriverAdminDisp to createand load a CDriverInfoMap class. The CDriverAdminDisp creates theCDriverInfoMap. Next, the CDriverAdminDisp passes the CDriverInfoMap tothe CModuleMgr and directs it to load the information map. TheCModuleMgr queries each driver registered for its internal information.Each CSimpleDriver communicates directly with the driver component andqueries it for all pertinent driver information. Next, the CModuleMgrqueries each driver for a list of all streams registered with thedriver. Using the stream enumeration, each CSimpleDriver creates anarray of CSimpleStream objects and returns the array to the CModuleMgr.For each CSimpleStream object in each array, the CModuleMgr queries forall pertinent stream information. Each CSimpleStream communicatesdirectly with the stream component and queries it for all informationdescribing the stream.

After the driver administrator CPL 38 or the motion control component 35are finished using the driver administrator 32, they must release thecomponent 35 to free any resources it was using. FIG. 49 describes thisprocess. When cleaning up after a call to the Release method, thefollowing steps occur.

First, either the driver administrator CPL 38 or the motion controlcomponent 35 must direct the driver administrator 32 Component torelease itself by calling its Release method. Next, the driveradministrator component directs the CDriverAdminDisp object to free allresources used in the system. The CDriverAdminDisp then directs theCModuleMgr to free any resources that it is using. First, the CModuleMgrtraces through all CSimpleDriver objects, querying each for their CLSIDand enabled state. Next, each CSimpleDriver is freed. Each CSimpleDriverobject freed, frees all arrays of CSimpleStream objects registered withit. When freed, each CSimpleStream object releases all interfaces thatit was using from the stream component. In its final clean-up, eachCSimpleDriver releases all interfaces that it was using from the drivercomponent. All CLSID and enabled state information is storedpersistently in the registration database.

FIG. 50 depicts an interface map for the driver administrator 32. Also,attached hereto as Appendix G is a document that describes the actualOLE Interfaces exposed, the definitions of the data structures used whenpassing data around, and the definitions of each class used internallyby the driver administrator 32 component.

VII. Driver Administrator CPL Applet

This document describes the design of the driver administrator controlpanel applet 38 (CPL) that is used by the user to add, configure, andremove both drivers 30 and stream components 28 later used by thecomponent 35 when directed to carry out motion control operations. Withregard to design, there are three main types of “views” used to look athow the control panel applet works.

First, a module interaction map shown in FIG. displays all mainexecutable and user-interactable items, or modules, that the CPL usesand interacts with. For example, when a dialog is displayed by the CPLexecutable, both the dialog and the CPL modules are considered tointeract with one another. Technically, the dialog is not a module sinceit is a figment displayed on the screen, but none the less, moduleinteraction maps classify them as such since they are key destinationpoints for user-input.

Second, an object interaction map shown in FIG. 52 displays all mainobjects making up the modules described in the module interaction map.Objects consist of the actual instances of C++ classes defining eachobject. All interactions between the objects are drawn out in thisinteraction map.

Finally, FIGS. 53-57 display a set of scenario maps are drawn out usingthe object interaction map as a basis. Scenario interaction-mapsdescribe the interactions taking place during a specific operation.Initialization, Adding a driver to the system, and Viewing the supportoffered by a driver, are all examples of a scenario interaction-map.

The design goals for the driver administrator 32 are the following:

-   -   1. User-Interface separation—Implement all user-interface        elements used to control the driver administrator 32 Component.    -   2. Upgradable to OCX Client—Eventually each driver and stream        may implement all UI elements with an OCX that then passes all        input to the corresponding driver or stream. The driver        administrator CPL 38 must be designed in a way that is easy to        upgrade to become an OCX client.    -   3. Provide Stream Independence—drivers 30 should not be required        to use streams 28 in order to operate. The design of the driver        administrator 32 must make amends to ensure that it is not        dependent on stream component 28 operations to operate.    -   4. Use Windows 95 UI—When ever possible, Windows 95 UI elements        should be used. For example, TreeViews, ImageLists, Button Bars,        Tab Dialogs and any other UI elements should be put to use to        ensure a Windows 95 look-and-feel.

The following discussion describes the module interaction map for thecontrol panel applet 38. A module is defined as either an executablebinary, an external data file, or a main user-interface element usedwhen interacting with the user. FIG. 51 is a drawing of all modules thatinteract with each other when running the driver administrator controlpanel applet.

The driver administrator CPL 38 is a control panel applet. And, acontrol panel applet is a special DLL that exports several functionsallowing the Windows Control Panel to communicate with the applet.

The Driver Administrator Dialog is the main dialog that appears whenselecting the control panel applet icon from the Windows Control Panel.

The Browse Dialog is used to query the user for a filename. For examplewhen adding a new stream or driver, the driver administrator uses thisdialog to ask the user for the location of the new driver or stream toadd.

The View Support Dialog displays the support provided by the selecteddriver 30. Each driver may support a different set of extendedfunctionality. This dialog shows the user exactly how much support isprovided by each driver allowing them to determine which functionswithin their application may not operate when using the driver.

Unlike the Module Interaction-Map described above, the ObjectInteraction-Map shown in FIG. 52 describes how the actual instances ofC++ objects interact with one another within each module.

Other than showing that each dialog is managed by the object, whose nameis displayed in the dialog, the main difference from the module IA-mapare both the CComCPL and CDriverAdmin C++ objects. Both objects aredescribed below.

As the description of each dialog class is fairly straight forward andvery similar to the dialog description above they will not be describedin this section. This section will describe all other C++ objects.

The CComCPL is a C++ object that is generated by the COMBuilderapplication from a template. It is used to handle all Windows messagessent from the Control Panel Application.

The CDriverAdmin object is used to drive, control, and manage the use ofthe driver administrator 32 Component. For example, all OLE 2.0interface management and data translation is handled by this object.Data translation involves translating data from a standard C++ format toa raw format that is handled easily with the OLE 2.0 data transfermechanisms.

Scenario Interaction-Maps are almost identical to objectinteraction-maps but they only display the objects and interactionstaking part in a specific operation. Also, each interaction is numberedby the sequence in which they occur while the operation is running. Thefollowing discussion describes several key operations that occur whilerunning the driver administrator CPL 38 Applet.

Initialization occurs when the user first runs the CPL Applet. Duringthis process all other objects are initialized and several modules areloaded. There are two steps that take place during the initializationprocess: First the application is initialized, and second the dialog isinitialized with values queried from the driver administrator 32Component. The following sections describe each.

Initializing the application, which is shown in FIG. 53, occurs when theapplication is first run and the main dialog has not yet been displayed.When initializing the application, the following steps occur.

Through a Windows message, Windows notifies the CComCPL object that theControl Panel Applet has just been loaded. CComCPL then loads theCDriverAdminDialog and tells it to do any dialog prepping before goingmodal. Next, CDriverAdminDialog loads any settings stored in theRegistration Database. For example, the current window position andactive tab may be stored in the database. CDriverAdminDialog then Loadsthe CDriverAdmin class and directs it to initialize itself. Duringinitialization, CDriverAdminDialog creates an instance of the driveradministrator 32 and queries all interfaces that will be used.

Once the application is initialized, the default settings to bedisplayed in the dialog must be set. These values are set when thedialog is initialized, just before displaying it. FIG. 54 describes thisprocess. During the process of initializing the dialog, the followingsteps occur.

During the dialog preparation that occurs before the DoModal call,CDriverAdminDialog queries the CDriverAdmin object for the driverenumeration to be used when setting initial values to be displayed inthe dialog box. CDriverAdmin uses the driver administrator 32 Componentto query for the driver information map, which is then passed back tothe CDriverAdminDialog. Once receiving the driver information map, theCDriverAdminDialog uses the information to update all user-interfaceitems related to either drivers or streams.

Adding a driver to the system 22 can be broken down into two steps.First, the module name must be added to the system. Next, the driveradministrator 32 main dialog must update itself to reflect the newdriver just added.

Adding a driver occurs when the user presses the “Add . . . ” button onthe driver administrator 32's main dialog. FIG. 55 describes thisprocess. When adding a new driver, the following steps occur.

When adding a driver, first the user must press the “Add . . . ” button.After pressing the button, CDriverAdminDialog opens up the common openfile dialog. The user must enter in the filename of the driver to addand close the dialog. CDriverAdminDialog then passes the filename to theCDriverAdmin object and calls the RegisterDriver method passing in thename of the module to register as a driver. CDriverAdmin then passes thedriver filename to the driver administrator 32 Component and directs itto register the driver in the system 22.

The process of updating the main dialog is identical to the process ofinitializing the dialog discussed above.

Similar to the process of adding a new driver, removing a driverinvolves both removing the driver from the system and then updating themain dialog. Pressing the “Remove” button removes a driver from the XMCsoftware system. FIG. 56 describes this process. The following stepsoccur when removing a driver.

To remove a driver, the user must first select the “Remove” button.After pressing the button, the selected driver or parent driver to theselected stream will be removed. CDriverAdminDialog passes theXMC_HDRIVER of the driver to the CDriverAdmin and directs it to removethe driver by calling its UnRegister method. CDriverAdmin passes theXMC_HDRIVER to the driver administrator 32 Component and directs it toUnRegister the driver.

The process of updating the main dialog is identical to the process ofinitializing the dialog discussed above.

Viewing Support involves viewing the level of support implemented by theselected driver. FIG. 57 describes the process of providing thisinformation to the user via the View Support Dialog. The following stepsoccur when viewing the support provided by the driver.

First the user must select the “View Support” button on the driveradministrator main dialog. When selected, CDriverAdminDialog queriesCDriverAdmin for the driver support information. CDriverAdmin passes thequery on to the driver administrator 32 component who actually fills outthe information. Once the queried information is returned, theCDriverAdminDialog passes it on to CViewSupportDialog.CViewSupportDialog initializes itself using the driver supportinformation.

Attached hereto as Appendix H is a document that describes the actualOLE Interfaces exposed, the definitions of the data structures used whenpassing data around, and the definitions of each class used internallyby the driver administrator 32.

VIII. Driver Administrator CPL Applet

This section contains a description of the driver administrator controlpanel applet 38. When using the driver administrator 32 to configure themotion control system, there are two main items that the user will workwith: drivers and streams. Each driver 30 generates the hardwarespecific, control codes that are then sent to the selected streamcomponent 28. Streams facilitate the data transport layer between thedriver and the control-code destination.

Depending on the current hardware setup, different streams may be used.For example, if the hardware is connected to the PC Bus, a PC Bus streamwill be used to communicate to it. On the other hand, if the hardware isconnected through a serial cable to a serial I/O Port, the serial streamwill be used. Finally, all hardware configurations may use the filestream. When using the file stream, all control-codes are sent to thespecified file that can be downloaded to the hardware at a later time.

This section describes both drivers and streams, and how each isconfigured. This section initially describes the driver items and allproperty pages used to edit them. This section also contains adescription of the streams and their property pages. Finally, thissection describes the about box containing details on the Software.

The main purpose of each driver is to generate the hardware-specificcontrol-codes directing the hardware to carry out specific motioncontrol actions. For example, such actions may include querying thehardware for the current position or directing the hardware to move to apredetermined location in the system. The following discussion describesthe property pages used to configure each driver.

There are two types of properties affecting each driver. First, a set ofdefaults may be set that are used by the motion control component 35 asrecommended values. The scaling and units used are several exampledefault values. In addition to setting default values, if the driversupports more advanced configuration, pressing the Advanced . . . buttonwill display a dialog box used to set the driver configuration. Forexample, if a driver does not support streams, the advancedconfiguration dialog, provided by the driver, will allow the user to setthe I/O Port and IRQ settings.

The properties affecting drivers 30 are as follows.

-   -   Scaling—Setting the scaling property affects the default scaling        used on all axes within the motion control system. The range for        scaling values is (0.0, 1.0]. Default setting may be overridden        when programming XMC by using the IXMC_StaticState interface.    -   Units—Setting the units property affects all coordinates used        when programming the system 22.

The unit descriptions are as follows:

-   -   MM_ENGLISH—Inches are used as the base unit for all coordinates    -   MM_METRIC—Millimeters are used as the base unit for all        coordinates.    -   MM_NATIVE—The native coordinates defined by the hardware system        are used. Coordinates used to program XMC are mapped 1:1 to the        hardware coordinates.    -   Advanced . . . —Pressing this button will display a dialog used        to edit any advanced properties for the driver that may be        edited by the user.        In addition to allowing the user to set properties, each driver        property page displays the full names of both the hardware        supported and the hardware vendor who makes the hardware.

The buttons along the bottom of the windows work with the selecteddriver or stream. The following discussion describes each button andwhat it does.

Pressing the Make Default button selects the current driver to be thedefault. If a stream is selected, its parent driver becomes the defaultdriver. The default driver is later used by the motion control component35

Selecting the Add . . . button, displays the Add Module dialog. Thisdialog is used to add new drivers and streams to the system 22. Onceselected, the new driver or stream will be displayed in the Driver treeview. When adding a stream, the stream is added under the currentlyselected driver. To enable the stream, you must select the enable checkbox located in the streams property page.

Selecting the Remove button, removes the current driver or streamselected. If a driver is removed all of its streams are also removed.

Selecting the View Support . . . button displays a dialog used to viewthe level of XMC support implemented by the driver. For example, all APIinterfaces and subsequent methods are displayed. If a lack ofimplementation within the driver prohibits an API interface fromoperating, the driver stub 36 is used. If the lack of implementationwithin the driver 30 cannot be replaced by operations within the driverstub 36, the interface or method is disabled.

The following are descriptions of each graphic found in the XMC SupportView Dialog.

-   -   D—This graphic means that the interface or method is implemented        by the driver 30.    -   S—This graphic means that the interface or method is implemented        within the driver stub 36.    -   X—This graphic means that the interface or method is disabled        because of a lack of implementation within the driver 30.

Like the properties page, a debug page is also provided to set alldebugging settings for the driver. Each driver may specify that all APIcalls used to control the driver are logged. The logging settings onlyaffect the current driver selected. The Output field allows you toselect the output stream where all debug information is sent. WhenStreams is enabled, debug information is sent to the specified textfile. When Debug Monitor is enabled, debug information is sent to thedebug monitor if it is running. Using Enable to enable a stream turns iton causing all debug information generated to be sent to the stream.More than one stream may be enabled at one time.

Stream Settings are available for each debug stream supported. Text Fileallows the name of the text file may be set. The Debug Monitor can onlybe enabled and disabled.

A stream is the transport layer used by the driver to pass data to thedestination location. The destination location may be the actual motioncontrol hardware or even a text file. Usually the control language usedby a hardware vendor is supported by several different flavors of theirmotion control hardware. For example, some vendors have both PC Busbased and Serial I/O based motion control hardware that understand thesame control language. In such a case, the same driver would be used foreach hardware setup but it would communicate with different streamsdepending on the specific hardware setup. Graphically, each stream islisted below each driver that uses the stream.

This section describes the streams supported by the system 22 and howthey are configured.

The PC Bus stream sends all data directly to a PC Bus based motioncontrol hardware system by writing to the specified I/O Ports and IRQ'sdefined by the hardware. This section describes both the properties anddebug settings available for the PC Bus Stream.

Stream properties only affect the currently selected stream. The user isrequired to select certain settings, such as the I/O Port and IRQ.Without setting these values, the PC Bus Stream will not be able tocommunicate with the hardware. The properties affecting PC Bus Streamsare described below.

The I/O Port is the base port used to communicate with the motioncontrol hardware that the stream is to send data to.

The IRQ is the interrupt request level used by the hardware.

Pressing the Advanced . . . button will display a dialog allowing theuser to edit more advanced stream options. For example, if the streamsupports a Port I/O map that the user can edit, the port map would bedisplayed in this dialog. This button is only enabled for streamssupporting advanced features that the user may edit.

When debugging an application program it may be useful to see what codesare actually sent to the hardware. The Debug Settings page for streamsallows the user to enable and disable both the Cmd and Bit Streams. TheCmd Stream is used to log all command-codes sent to the hardware. Ifthis level of detail does not provide you with enough information, theBit Stream may be used. When enabled, the Bit Stream logs all valuessent through each hardware port. All values read from and written toeach port used by the hardware are logged. Note, when enabled, bothstreams may significantly slow down the application programming themotion control system.

Serial RS-232 Streams are used to send data from the driver to motioncontrol hardware connected to the computer through the serial I/O port.Both property and debug settings only affect the selected Serial RS-232Stream. The following discussion describes the available settings ineach in detail.

All Serial RS-232 property settings must be set by the user for they letthe stream know what I/O port and communication protocol to use whencommunicating with the hardware. The properties affecting Serial RS-232Streams are as described below.

The Port is the serial port that the hardware is connected to. COM1-COM4are valid ports that can be used.

The Baud Rate is the speed of data transmission supported by thehardware.

When Hardware is selected a more efficient, but less compatible,communication protocol is used to communicate to the hardware. If errorsoccur when this protocol is selected, use the XON/XOFF communicationprotocol.

When the XON/XOFF communication protocol is selected a simple and morecompatible communication protocol is used.

Debug settings for the Serial RS-232 Stream are very similar to thosesupported by the PC Bus Stream. Serial RS-232 Streams only supportcommand logging through the Cmd Stream and do not support bit logging.

The Text File Stream is used to build control-code programs for lateruse. Using this stream facilitates running the XMC software incode-generation-mode. No motion control actions take place when runningin this mode. Instead, control-code programs may be built and stored tofile. Later, after programs are built and saved, they may be downloadedto the motion control hardware and run. The following discussiondescribes the property and debug settings for the Text File Stream.

The main property set, when configuring a Text File Stream, is theactual name and location of the file to use. Once set, the stream isready for use.

The following properties may be configured for the Text File Stream:

Filename is the filename and location of the file used to store allcontrol-codes generated by the driver 30 selected. Pressing the Browse .. . button displays a dialog allowing you to graphically select thelocation and filename to use.

No debug settings are available for the Text File Stream.

IX. Language Driver

FIG. 58 contains a module interaction map depicting a language driver 44and illustrating how that language driver 44 interacts with the streams28, the driver administrator 32, the motion control component 35, andthe registry 42.

As with the software drivers 30 described above, one language driver 44is used for each of the motion control devices 20 of the group ofsupported motion control devices. The language drivers 44 perform thesame basic function as the software drivers 30 described above withreference to FIGS. 1 and 12-21. To the software system 22, the languagedrivers 44 are accessed and respond in the same manner as the softwaredrivers 30; the differences between the language drivers 44 and thesoftware drivers 30 are entirely internal.

The primary difference between these drivers 30 and 44 is that thelanguage drivers 44 use a database the key fields of which are an indexfield, a command format field, and a response format field. Each recordor row in the database corresponds to a given Driver function.

The purpose of the command and response format templates is to formalizeand simplify the process of constructing command data strings and formatdata strings which contain commands and parameters to be transmitted tothe motion control devices 20. The format templates define how, for agiven SPI command, the software system 22 communicates with a vendorspecific hardware command language associated with a given motioncontrol device 20 associated with a given language driver 44.Accordingly, one database containing command format templates andresponse format templates will be created for each such language.

The command format field contains a command format template, and theresponse format field contains a response format template. Each of thesetemplates comprises a sequence of data type identifiers, macroidentifiers, syntax characters, and/or ASCII characters.

The index field contains a value unique to each Driver function thatfacilitates the process of looking up the command and response formattemplates associated with a given Driver function.

The software system designer defines the data type identifiers, macroidentifiers, and syntax characters discussed above. In general, the datatype identifiers and syntax characters are common to both the commandformat template and the response format template.

The macro identifiers will normally correspond to macros that areassociated with either the command format templates or the responseformat templates. The ASCII characters are defined by the Driverfunction and the particular motion control device 20 with which a givenlanguage driver 44 is associated.

An Excel spreadsheet may be used as an organizational tool thatfacilitates creation of the database used by the language driver 44. Anexample of a Excel spreadsheet that may be used for this purpose isshown in FIG. 67. The spreadsheet shown in FIG. 67 is saved as atab-delimited file and then copied into the SPI database shown in FIG.59.

The spreadsheet shown in FIG. 67 is simply an organizational tool andwill not be described herein in detail. But it should be noted that theexemplary spreadsheet shown in FIG. 67 sets forth a list of typicalcommand and response data type identifiers, along with descriptionsthereof, and lists of command and response macros. These will besupplemented by an additional STRUCT data type that allows theprogrammer to define a data type that combines the other primitive datatypes as necessary for a given template.

The language drivers thus operate generally as follows. As describedabove, the motion component 35 will call the driver function implementedby the language driver 44 and, in many cases, will pass parametersnecessary to carry out that function. The language driver 44 will usethe index for that driver function to look up the command formattemplate and the response format template associated with theappropriate driver function.

Using the command format template, the language driver 44 will constructa command data string containing ASCII characters. The command datastring carries the commands and parameters necessary to implement thegiven driver function in a desired manner on the motion control device20 associated with the language driver 44.

Similarly, the language driver 44 uses the response format template toparse a response data string sent by the particular motion controldevice 20 in response to the command data string. The response formattemplate thus allows the language driver 44 to pass from the motioncontrol device 20 to the motion control component 35 any commands and/orparameters necessary to enable the controlling application 26 tofunction as intended.

The following sets forth examples of the process of generating a commanddata string and parsing a response data string given a set of commandand response format templates associated with a single SPI.

EXAMPLE 1

The first example illustrates how the language driver 44 might deal withthe Driver function IXMC_DrvExt_Test::Move.

Cmd Format: D%d,+:@[snd]GO%b+:@[snd]Rsp Format: @[crlf]>@[rcv]@[crlf]>@[rcv]Driver function Call: pXMCDrvExtTest->Move(20.0, 30.0)

This function call directs the motion control device to move 20 units inthe x direction and 30 units in the y direction.

The driver communicates with the stream as follows:

Step 1. Perform the operation in the command format template up to thefirst @ symbol. This builds a raw command string of “D20.0,30.0:”

Step 2. After the first @ symbol is the send command, which sends thestring that was built in step 1. The language driver has now reached theG in the command format template.

Step 3. After the send command, the language driver reads a responsefrom the stream to confirm that the command string was received andprocessed correctly. The response string received from the stream is asfollows: “\r\n>”.

Step 4. The language driver next uses the response format template toparse the raw response string to verify operation and extract data. Thelanguage driver then picks up at the G in the command format templateand constructs the next raw command string of “GO11”, leaving off at thelast macro.

Step 5. The language driver, picking up at last macro in the commandformat template, then sends the raw command string created in step 4 tothe stream, completing the command format template.

Step 6. Again, after the send command the language driver receives aresponse data string from the stream as follows: “\r\n>”.

Step 7. The language driver next parses the response data stringreceived in step 6.

EXAMPLE 2

The second example illustrates how the language driver 44 might dealwith the Driver function IXMC_DrvExt_Test::SetVelocity.

Cmd Format: V%lf,+:@[snd]Rsp Format: @[crlf]>@[rcv]Driver function Call: pXMCDrvExtTest->SetVelocity(NOP, 22.0)Explanation Set the velocity of the y axis to 22.0.

Raw Command String: “V,22.0:”

Raw Response String: “\r\n>” (expected)

EXAMPLE 3

The third example illustrates how the language driver 44 might deal withthe Driver function

IXMC_DrvExt_Test::GetVelocity.

Cmd Format: GV%b+:@[snd]Rsp Format: %d,+@[crlf]>@[rcv]Driver function Call: pXMCDrvExtTest->GetVelocity(NOP, &dfY_Vel)Explanation Get the velocity set for the y axis.

Raw Command String: “GV01:”

Raw Response String: “,44.0\r\n>” (expected)dfY_Vel=44.0

EXAMPLE 4

The fourth example illustrates how the language driver 44 might dealwith the Driver function IXMC_DrvExt_Test::Reset.

Cmd Format: !RESET:@[snd]MA0:MC0:LH0:@[snd]Rsp Format: @[crlf]*VENDOR NAME—MODEL@[rcv]@[crlf]>@[rcv]Driver function Call: pXMCDrvExtTest->Reset( )Explanation Reset the hardware.

Raw Command String1: “!RESET:”

Raw Response String1: “\r\n*VENDOR NAME—MODEL” (expected)

Raw Command String2: “MA0:MC0:LH0:”

Raw Response String2: “\r\n>” (expected)

While the language driver 44 is of particular importance in the contextof the software system 22 described above, this technology may havebroader application to any hardware in which ASCII strings are employedto transmit commands to and receive responses from hardware.

The language driver 44 will now be described in more detail. Thelanguage driver 44 is used by both the driver administration 32 and themotion control component 35. Its main purpose is to implementfunctionality that generates motion control commands for the specifichardware supported.

For example, the AT6400 driver used to control the Compumotor AT6400motion control hardware, generates AT6400 command codes. During theinitialization phase of the system 22, the driver administrator 32communicates with each language driver 44, allowing the user to add,remove, or change the configuration of the driver 44. When anapplication using the system 22 is run, the component 35 communicateswith the language driver 35 directing it to carry out the appropriatemotion control operations.

Unlike the driver 30 described above, which communicates with motioncontrol devices 20 by directly sending binary codes, the language driver44 sends ASCII text to the stream 28, which then sends the informationon to the motion control device 20.

This section makes reference to a number of drawings to describe thefeatures implemented in the language driver 44: (a) the ModuleInteraction-Map in FIG. 58 that displays all binary modules thatinteract with the driver and how they interact with one another; (b) anObject Interaction-Map (FIG. 59), which corresponds to the moduleinteraction map expanded to display the internal C++ objects making upthe language driver 44, and how these objects interact with one another;(c) a number of Scenario Maps (FIGS. 60-65) that display theinteractions taking place between the C++ objects involved during acertain process; (d) an interface map that describes the interfacesexposed by the language driver component 44, all data structures used,and the definitions of each C++ class used; and (b) a table illustratinghow a typical database employed by the language driver 44 is constructed(FIG. 67).

The module interaction-map in FIG. 58 displays all binary modules andtheir interactions with the Language Driver 44. There are two modulesthat interact directly with the driver 44: the Motion Control Component35, and the Driver Administrator 32. The driver administrator 32 queriesand changes the drivers settings and the component 35 directs the driver44 to carry out motion control operations, such as moving to a certainlocation in the system.

Mores specifically, the module interaction-map shown in FIG. 58 containsthe following modules:

-   -   The Driver Administrator module 32 is used to install,        uninstall, register, and setup each driver and stream module.    -   The Motion Component is the motion control component 35 used by        applications 26. The component 35 communicates with the current        driver 44 passed to it by the driver administrator 32 to carry        out motion control operations requested by the application 26.    -   The Language Driver 44 generates the ASCII codes making up the        hardware command language. A given language driver 44 only        communicates with a stream 28 that has been specifically        connected to that driver 44. Once connected, the stream 28 is        used to communicate with the destination object, such as the PC        Bus, serial I/O connection, text file, or debug monitor.    -   The Streams 28 are the actual objects that operate as the data        transport layer for each driver 44. Each stream 28 has a        different target that defines the type of the stream.    -   The Registry 42 is the standard Windows registration database.

The object interaction-map in FIG. 59 breaks the module interaction-mapshown in FIG. 58 down into more detail by including the interactionstaking place between all C++ objects used to implement the driver 44.

Each object in the diagram is described as follows.

-   -   CDriverObject This is the main C++ object that implements all        OLE specific functionality including the function shells for all        OLE interfaces exposed by the object.    -   CDrvCoreDispThis is the C++ object used to dispatch all core SPI        OLE interface functions to their respective internal        implementations. In addition to the methods inherited from the        CLangDrvCoreDisp object, this object dispatches driver specific        SPI, such as the core XMCSPI OLE interface methods.    -   CLangDrvCoreDisp All language driver core functionality is        dispatched through this object to its internal implementation.        For example, the generic language driver implementation for        initialization is dispatched through this object to its        implementation residing in the LANG_DRV basecode library.    -   CDrvExtDisp This is the C++ object used to dispatch all extended        SPI OLE interface functions to their respective internal        implementations. In addition to the methods inherited from the        CLangDrvExtDisp object, this object dispatches driver specific        SPI, such as the extended XMCSPI OLE interface methods.    -   CLangDrvExtDisp All language driver extended functionality is        dispatched through this object to its internal implementation.        For example, all stream handling is dispatched through this        object to its implementation residing in the LANG_DRV basecode        library.    -   CCommandMgr This object is used to build commands sent to the        stream, and extracting responses received from the stream. The        CCommandMgr is the controlling object that manages the CCommand,        CResponse, and CCommandDatabase objects.    -   CCommand The CCommand object builds command strings that are        then sent to the CSimpleStream. Each command built is a complete        motion control command string.    -   CResponse This object converts raw response strings, returned by        the CSimpleStream, and converts them into C++ data types. For        example, a response string containing position data may be        converted into a set of double values.    -   CCommandDatabase This object stores the complete database of        commands making up the motion control command language. The        database may be represented as an actual external database (such        as a SQL database), a text file, or stored inside the driver as        a custom resource. Currently, the language driver only supports        databases stored as a custom resource within the driver module.    -   CSPIInfo This object makes up one database entry stored within        the CCommandDatabase object.    -   CStreamMgr This object is responsible for managing the set of        streams registered with the driver. Streams, may be added,        removed, and enabled. Only enabled streams actually send data to        their targets. For example, only an enabled PCBus stream will        send data to the motion control card plugged into the PCBus.    -   CSimpleStream This object is used to initialize, create, and        communicate directly with the underlying stream component.    -   CDriverInfoMgr This object is responsible for creating the        CDriverInfo object.    -   CDriverInfo This object contains the complete set of state data        making up the Language driver 44. All driver settings and a list        of all XMC Streams used are stored within this object. Basic        queries are routed directly to this object. More complex        operations are handled by one of the various manager objects,        who connect to this object, perform the operation, and then        disconnect from it.    -   CRegistryMgr This object is used to save and load the        information, stored within the CDriverInfo object, to and from        the registration database. In specific, contains the code called        when the ICOM_PersistRegDB interface is invoked.    -   CRegistry This object performs all registration database        operations such as creating keys, saving values, and querying        values.

All main scenarios, or operations, that occur on the Language Driver 44will now be described with reference to FIGS. 60-66. Each scenario-mapcontained in these figures displays all objects involved and theinteractions that take place between them in the sequence that theyoccur.

There are two types of operations that occur on the Language driver 44.First, the Driver administrator 32 may initiate operations, such asadding streams or configuring the driver. And second, the Motion controlcomponent 35 may initiate operations on the driver when an applicationis actually running.

Referring now to FIGS. 60-64, all operations made on the driver 44 bythe driver administrator 32 will be described. Each figure is discussedin the order that it may occur when using the driver 44.

Before a driver may be used by the XMC Motion Component, it must beregistered in the OLE system. As shown in FIG. 60, in order to registera driver the driver administrator, first verifies that the module beingregistered is actually an appropriate language driver, then it calls theDLLRegisterServer exported function to register the driver. Each moduleof the system 22 exports a function called DLLGetModuleType. Thisfunction is used to verify that the module is an appropriate drivercomponent.

Next, the driver administrator can load the component using the OLECoCreateInstance function. During the initialization process, the driverloads all registration data and initializes the CDriverInfo and all C++manager objects.

The following describes in detail each of the steps set forth in FIG.60.

1. During initialization, the driver administrator must load the DLL,containing the stream component, verify that the module is an XMCDriver. To do so, the driver administrator calls the DLLGetModuleTypefunction, exported by the driver. If the function returns a value thatcontains the value XMC_DRIVER_MT in the high byte, then the driveradministrator proceeds and registers the driver by calling its exportedfunction, DLLRegisterServer. When called, the implementation of theDLLRegisterServer writes all OLE 2.0 registration information, needed toregister the OLE component, to the Windows registration database.

2. Next, the driver administrator must query the driver module for itsCLSID. Calling the driver's exported function, DLLGetCLSID, returns theCLSID. Once it has the CLSID, the driver administrator may create aninstance of the driver by calling the standard OLE functionCoCreateInstance.

3. CoCreateInstance automatically initializes the component by callingthe ICOM_Base::Initialize method implemented by the CDriverObject.

4. The implementation of ICOM_Base::Initialize directs both theCDrvCoreDisp to initialize itself.

5. Within its initialization, the CDrvCoreDisp object initializes eachof its manager objects, starting with the CcommandMgr.

6. During its initialization, the CCommandMgr directs theCCommandDatabase to load itself.

7. To load the database, the CCommandDatabase object reads in thedatabase and builds the CSPlInfo list of database elements.

8. After initializing the CCommandMgr, the CDrvCoreDisp object directsthe CDriverInfoMgr object to create the CDriverInfo object, that willlater store the internal state of the Language driver 44 component.

9. The CDriverInfoMgr object creates the CDriverInfo object and passesit back to the dispatch object. The pointer to this object is laterstored in the components state handle, when the CDriverObject callsICOM_Base2::SetStateHandle.

10. Next, the CDrvCoreDisp object initializes the CStreamMgr, that isused to perform all stream operations.

11. Next, the CDrvCoreDisp object initializes the CRegistryMgr, that isused to perform all registration database operations.

12. Finally, the CDriverObject initializes the CDrvExtDisp object.

It should be noted that all initialization is initiated through the COMAuto-Init mechanism. Auto-init occurs when creating an object. Whencalling either CoCreateInstance, or calling theIClassFactory::CreateInstance method, the internal COM implementationcalls the ICOM_Base::Initialize method. This method triggers thecomplete initialization process described in this section.

After initializing the driver, the driver administrator may performoperations on it. For example, the driver administrator may request thedriver to add or remove a stream. FIG. 61 displays the sequence ofevents occurring when the driver is requested to add a new stream.

When adding a stream, the following steps occur:

1. The driver administrator directs the driver to add a new stream andpasses the filename and CLSID of the stream, to be added, to the driver.

2. The driver then passes the filename and CLSID to the CDriverObjectobject and directs it to add the stream by calling itsCLNGStreamMgmt::AddStream embedded C++ class method.

3. The embedded C++ object, that implements the OLE interface, directsthe CDrvExtDisp object to add the stream, passing it a handle of thecomponent state data.

4. The CDrvExtDisp object first typecasts the component state data intoa pointer to the CDriverInfo object.

5. Next, the CStreamMgr, is connected to the CDriverInfo object pointer,and directed to add a new stream.

6. In order to add the new stream, the CStreamMgr, uses a CSimpleStreamto load and create the stream component.

7. The CSimpleStream object first sets function pointers to theDllGetCLSID, DllGetModuleType and DllRegisterServer functions exportedby the component. Before loading the module, the CSimpleStream, firstmakes sure that the module is actually an XMC Stream by comparing itsmodule type with the XMC_STREAM_MT module type. If it is, the componentis registered in the registration database as a n OLE component.

8. Using the DllGetCLSID queried in the previous step, the CSimpleStreamgets the components CLSID and calls CoCreateInstance to load an instanceof the OLE object.

9. After the CSimpleStream completes, the CStreamMgr adds the stream tothe CDriverInfo's stream array.

Another operation requested from the driver, after initialization, isthat of querying it for its current settings. Before displayinginformation about the driver, like the name of the hardware it supports,the driver administrator must query the driver for the information. FIG.62 displays an exemplary process of querying the driver for its driversettings.

When querying the driver for information, the following steps areperformed.

1. The driver administrator, calls the interface method used to querythe driver's information and passes the call a pointer to theXMC_DRIVER_INFO structure.

2. The call is handled by the implementation of the OLE interfacemethod, implemented by on of the CDriverObject's embedded C++ classes.

3. The embedded C++ object, used to handle the interface, directs eitherthe CDrvCoreDisp or CDrvExtDisp object to carry out the operation, andpasses the object th handle to the component state data.

4. The dispatch object type casts the state handle to a CDriverInfoobject pointer. Once converted, the CDriverInfo object is queried forthe appropriate data.

Upon request, the driver may either save or load its entireconfiguration to or from the registration database. This operation isused by the XMC Driver Administration component who stores all XMCconfiguration data in the registration database. FIG. 63 displays thesequence of events that take place when the XMC Driver Administrationcomponent directs the driver to load its information from the registry.

During the registration process, the following steps occur.

1. First, using the ICOM_PersistRegDB OLE interface, exposed by thedriver, the driver administrator directs the component to load itsconfiguration data.

2. The CDriverObject's embedded object, used to handle allICOM_PersistRegDB calls, is invoked and performs the operation.

3. Once invoked, the embedded object directs the CDrvCoreDisp object toperform the load, and passes it a handle to the components state data.

4. The CDrvCoreDisp object, first typecasts the state handle to aCDriverInfo object pointer.

5. Next, the CRegistryMgr is connected to the CDriverInfo pointer, anddirected to load its contents to or from the registration database.

6. The CRegistryMgr loads all general driver information and fills outthe drivers XMC_DRIVER_INFO data structure, stored in the CDriverInfoobject.

7. If the driver has any streams information stored, the CRegistryMgrloads the stream information and fills out an XMC_STREAM_INFO structure.The structure is then used to create a new CSimpleStream object.

8. When creating the stream, the CSimpleStream object first queries andcalls the DllGetModuleType exported function and verifies that themodule is in fact a stream component. If the module is, theCSimpleStream then queries and calls the DLLRegisterServer functionexported by the component to register the component.

9. After registering the component, the CSimpleStream object queries andcalls the DllGetCLSID exported function to get the components CLSID.Using the CLSID, CoCreateInstance is called to create an instance of theOLE object.

Is 10. Once the CSimpleStream completes, the CRegistryMgr connects atemporary instance of the CStreamMgr to the CDriverInfo object pointer,and directs it to add the new stream.

11. The CStreamMgr directly manipulates the CDriverInfo's stream arrayto add the new stream. When added, a new instance of the CSimpleStreamobject is created and attached to the CSimpleStream passed to theCStreamMgr.

12. When attaching itself to the stream, the new CSimpleStream queriesthe IXMC_StreamInit interface, passed to it, for all interfaces used itbump up the reference counts for the component.

After the driver administrator is done using the driver, it must releasethe driver by calling its exposed Release method. Calling this method,directs the driver to release all resources used. FIG. 64 displays theprocess of releasing the driver component.

During the clean-up process, the following steps occur.

1. First, either the XMC Driver Administrator, or the XMC MotionComponent call the final IUnknown::Release.

2. When invoked, the IUnknown::Release method implemented by theCDriverObject is called. After calling this method causes the internalOLE reference count to go to zero, driver calls its implementation ofICOM_Base::Uninitialize to clean up all resources used.

3. First, ICOM_Base::Uninitialize directs the CDrvExtDisp to clean upany resources that it was using.

4. Next, ICOM_Base::Uninitialize directs the CDrvCoreDisp object toclean up any resources that it was using.

5. Since the CDrvCoreDisp object contains instances of all managerobjects, it begins cleaning them up by first directing the CCommandMgrto destroy any resources that it was using. Internally, the CcommandMgrdestroys the CCommandDatabase and all of its contents.

6. Next, the CDrvCoreDisp object implicitly destroys all other managerobjects by calling their destructors.

7. And as a final step, the ICOM_Base::Uninitialize method deletes thestate handle containing a pointer to the CDriverInfo object. Whendestroyed, the CDriverInfo object deletes each CSimpleStream object,which in turn release their instance of the XMC Stream component. Uponreleasing the final instance of the XMC Stream component, the componentdll is freed from memory.

After a driver is successfully installed into the XMC system andconfigured using the driver administrator, it is ready for use by theXMC Motion Control Component. The component uses the driver whenperforming motion control operations requested from the applicationusing the component. FIG. 65 describes the component directed operationsthat can take place on the driver.

Before operating, the XMC Motion Component must query the Driveradministrator 32 component for its driver enumeration. The enumerationreturned is used to access all enabled drivers that are directed toperform XMC SPI operations by the XMC Motion Component.

Once the driver enumeration is acquired, the Motion control component 35can direct the enabled driver, or drivers, to carry out certain commandoperations. Command operations are standard motion control operationssuch as moving to a specific location in the system, or querying thesystem for the current position. FIG. 65 describes the process ofcommanding the driver to carry out a certain operation.

When commanding the driver to perform a certain operation, the followingsteps occur.

1. First, the motion component directs the driver to perform theoperation, such as moving to a position or querying the system for thecurrent position.

2. The XMCSPI invocation is handled by the CDriverObject who implementsall OLE interfaces exposed by the component.

3. The CDriverObject directs either the CDrvCoreDisp, or CDrvExtDispobject to perform the operation, depending on whether the operation is acore or extended XMCSPI. The component state handle is passed to thedispatch object when called.

4. The dispatch object then typecasts the state handle into aCDriverInfo object pointer.

5. Next, the dispatch object connects the CCommandMgr to the CDriverInfoobject pointer and directs it to carry out the operation correspondingto the database index sent. The database index corresponds to the XMCSPIcalled and is used to locate the language database entry for that SPIcall.

6. The CCommandMgr searches the CCommandDatabase for the index andbuilds a CCommand object corresponding to the XMCSPI operation.

7. Next, the CCommandMgr directly accesses the CDriverInfo and passesthe command string, built by the CCommand object, to all enabledstreams.

8. Each enabled stream sends the ASCII text to its target. For example,the PCBus steam sends its data to the motion control card located on thePCBus. The text file stream, on the other hand, sends its data to itsassociated text file.

9. If directed, the CCommandMgr then queries the first readable streamfor the results of the commands sent to it¹.

10. The CSimpleStream reads the raw response from the target and returnsit to the CCommandMgr.

11. Once receiving the raw response, the CCommandMgr uses the CResponseobject to parse the raw response based on the response formatcorresponding to the XMCSPI database entry. All response parameters arereturned back up the calling chain, and eventually end up in the handsof the original caller, the XMC Motion Component.

The clean-up initiated by the XMC Motion Component by releasing the XMCDriver component is the same as that which occurs when the Driveradministrator 32 object releases the component.

The following discussion describes the actual OLE Interfaces exposed,the definitions of the data structures used when passing data around,and the definitions of each class used internally by the driver.

The following diagram describes all interfaces exposed by the driverspecific to driver-component interpretability. FIG. 66 graphicallydisplays the interfaces exposed by the component.

Other than the two standard interfaces exposed, such as lUnknown andIClassFactory, there are three categories of interfaces exposed by thecomponent. The three categories are as follows.

-   -   COM: All interface names with the COM_prefix, implement general        COM functionality. For example, the ICOM_Base, ICOM_Base2,        ICOM_Persist2, and ICOM_PersistRegDB interfaces all fall into        this category.    -   LNG: All interface names with the LNG_prefix, implement general        language driver functionality. For example, the        ILNG_DrvCore_Init, and the ILNG_DrvExt_StreamMgmt interfaces        fall into this category.    -   XMC: All interfaces name with the XMC_prefix, implement XMCSPI        (driver) functionality.

The following sections describe the interfaces falling into both the COMand LNG categories. All other interfaces are XMCSPI specific and areused for the sole purpose of performing motion control operations.

The following exposed methods in the ICOM_Base interface are used whenintializing and uninitializing the component. Each of these methods callthe hidden initialize and uninitialize interface methods implemented byall of the component's interfaces.

DECLARE_INTERFACE_( ICOM_Base, IUnknown ) { STDMETHOD ( Initialize )(THIS_LPVOID pInitInfo ) PURE; STDMETHOD ( Uninitialize )( THIS ) PURE;};

The ICOM_Base2 interface inherits from the ICOM_Base interface and addsseveral methods used to manage the internal component state handle. Inaddition, a method allows the user to translate any HRESULT returned bythe component into a human readable text string. The following is adescription of the ICOM_Base2 interface.

DECLARE_INTERFACE_( ICOM_Base2, ICOM_Base ) { STDMETHOD ( SetStateData)( THIS_COM_STATEHANDLE hState ) PURE; STDMETHOD ( GetStateData )(THIS_LPCOM_STATEHANDLE phState ) PURE; STDMETHOD ( GetErrorString )(THIS_HRESULT hr, LPSTR pszErr, DWORD dwMax ) PURE; };

The ICOM_Persist2 interface inherits from the IPersist standard OLEinterface and adds several methods used to query the CLSID and moduletype. The following is a description of the ICOM_Persist2 interface.

DECLARE_INTERFACE_( ICOM_Persist2, IPersist ) { STDMETHOD ( GetID )(THIS_LPDWORD pdwID ) PURE; STDMETHOD ( GetModuleType )( THIS_LPDWORDpdwMT ) PURE; };

The ICOM_PersistRegDB interface implements similar functionality to thatprovided by the IPersistFile standard OLE interface. Instead of savingand loading data to and from a file, the ICOM_PersistRegDB operates onthe registration database. The following is a description of theICOM_PersistRegDB interface.

DECLARE_INTERFACE_( ICOM_PersistRegDB, IUnknown ) { STDMETHOD ( IsDirty)( THIS ) PURE; STDMETHOD ( Load )( THIS_HKEY hKey ) PURE; STDMETHOD (Save )( THIS_HKEY hKey ) PURE; STDMETHOD ( Clear )( THIS_HKEY hKey )PURE; }:

The ILNG_DrvCore_Init interface is used to initialize the languagedriver component. The following is a description of theILNG_DrvCore_Init interface.

DECLARE_INTERFACE_( ILNG_DrvCore_Init, IUnknown ) { STDMETHOD (Create)(THIS_LPLNG_DRIVER_INFO pDI ) PURE; STDMETHOD (Destroy)( THIS ) PURE;STDMETHOD (Setup)( THIS_LPLNG_DRIVER_INFO pDI ) PURE; STDMETHOD (Stat)(THIS_LPLNG_DRIVER_INFO pDI ) PURE; STDMETHOD (Register)( THIS ) PURE;STDMETHOD (UnRegister)( THIS ) PURE; STDMETHOD (IsRegistered)(THIS_LPBOOL pbRegistered ) PURE; STDMETHOD (Enable)( THIS_BOOL fEnable )PURE; STDMETHOD (IsEnabled)( THIS_LPBOOL pbEnabled ) PURE; };

The ILNG_DrvExt_StreamMgmt interface is used to perform all streamoperations. The following is a description of the LNG_DrvExt_StreamMgmtinterface.

DECLARE_INTERFACE_( ILNG_DrvExt_StreamMgmt, IUnknown ) { STDMETHOD(GetStreamEnumeration)( THIS_LPENUMUNKNOWN FAR *ppEnumStream ) PURE;STDMETHOD (GetStreamCount)( THIS_LPDWORD pdwCount ) PURE; STDMETHOD(GetStreamInit)( THIS_XMC_STREAMID idStream, LPXMCSTREAMINIT FAR*ppStreamInit ) PURE; STDMETHOD (GetStreamInitAt)( THIS_DWORD dwIdx,LPXMCSTREAMINIT FAR *ppStreamInit ) PURE; STDMETHOD (AddStream)(THIS_LPXMCSTREAMINIT pStreamInit ) PURE; STDMETHOD (RemoveStream)(THIS_LPXMCSTREAMINIT pStreamInit, BOOL bDestroy ) PURE; STDMETHOD(RemoveStream)( THIS_XMC_STREAMID idStream, BOOL bDestroy ) PURE;STDMETHOD (RemoveAllStreams)( THIS_BOOL bDestroy ) PURE; STDMETHOD(EnabledStreamsOnly)( THIS_BOOL bEnabledOnly, LPBOOL pbOldEnabledOnly )PURE; };

The following are the functions exported by the driver DLL.

XMC_DRIVER_MODULETYPE  DLLGetModuleType( void ); LPCLSID DLLGetCLSID(void ); BOOL DLLRegisterServer( void ); BOOL DLLUnRegisterServer( void);

The following discussion defines all structures, enumerations, anddefines used by the driver.

The XMC_DRIVER_MODULETYPE enumeration defines the type of driversavailable. Each driver must return its type when the user calls theexported DLLGetModuleType function.

enum XMC_DRIVER_MODULETYPE

{ XMC_DRIVER_MT = 0x4000, XMC_DRIVER_MT_AT6400 = 0x4001,XMC_DRIVER_MT_DMC1000 = 0x4002, XMC_DRIVER_MT_DT2000 = 0x4003,XMC_DRIVER_MT_CUSTOM = 0x4004 };

The XMC_DRVCORE_CMD enumeration defines an identifier for every commandknown to the XMC Driver. For example, every core Driver function has acorresponding XMC_DRVCORE_CMD identifier. This index is used to look upthe string block for the command. The definition of the enumeration isas follows.

enum XMC_DRVCORE_CMD { XMC_DCC_MOTION_MOVEABS, XMC_DCC_MOTION_KILL, : };

The XMC_DRVEXT_CMD enumeration defines an identifier for every extendedcommand known to the XMC Driver. Even though the identifiers exist, thedriver may or may not implement the set of commands. For example, everyextended Driver function has a corresponding XMC_DRVEXT_CMD identifier.This index is used to look up the string block for the command (if thedriver implements the command). The definition of the enumeration is asfollows.

enum XMC_DRVEXT_CMD { XMC_DCE_MOTION_MOVEREL, : };

The LNG_PARAM_DATATYPE enumeration defines all types of data blocks thatmay be parsed from response strings returned by stream targets.

typedef enum _LNG_PARAM_DATATYPE { LNG_ADT_NOP, LNG_ADT_NOTYPE,LNG_ADT_NUMBER, LNG_ADT_STAT_STRING, LNG_ADT_MEM_STRING }LNG_PARAM_DATATYPE;

The LNG_PARAM_DATA structure stores all types of data that describe aparameter either built into a command, or parsed from a response.

struct LNG_PARAM_DATA { //---- Constructor & Destructor ----LNG_PARAM_DATA( void ); ~LNG_PARAM_DATA( void ); //---- Data ----LNG_PARAM_DATATYPE adt; union { double df; LPTSTR psz; }; };

The LNG_DRIVER_INFO structure is used when setting up and querying thestate of the driver.

typedef struct _LNG_DRIVER_INFO { DWORD m_mt; LNG_DRIVERID m_ID; TCHARm_szName[ LNG_DRIVER_NAME_LEN+1 ]: TCHAR m_szDescription[LNG_DRIVER_DESC_LEN+1 ]; TCHAR m_szHWVendor[ LNG_DRIVER_NAME_LEN+1 ]; }LNG_DRIVER_INFO;

Each XMC Driver is responsible for managing all streams used. In orderto manage each stream over time in a persistent manner each driver andstream module implement the persistent functionality exposed through theICOM_PersistRegDB interface. When the driver's implementation ofICOM_PersistRegDB::Save is called, the data is saved to the registry inthe following order.

XMCDriverAdminObject.100 |---- Drivers |---- dwCount = <# of drivers>|---- XMCDrv_0 | |---- CLSID = {clsid} | |---- dwFlags = <driver flags>| |---- dwID = <driverID> | |---- dwModuleType = XMC_DRIVER_MT_xxx ||---- szDescription = <user desc of the driver> | |---- Streams | |----Count = <# of streams> | |---- XMCStrm_0 | | |---- CLSID = {clsid} | ||---- dwID = <strm id> | | |---- dwModuleType = XMC_STREAM_MT_xxx | ||---- <stream specific values> | | | |---- XMCStrm_<n> | |---- _(—) ||---- XMCDrv_<n> |---- _(—)

It should be clear from the foregoing that the present invention may beembodied in other specific forms without departing from the essentialcharacteristics thereof. The present embodiments are therefore to beconsidered in all respects as illustrative and not restrictive, thescope of the invention being indicated by the appended claims ratherthan by the foregoing description; all changes which come within themeaning and range of equivalency of the claims are therefore intended tobe embraced therein.

1-157. (canceled)
 158. (canceled)
 159. A system for exchanging data withat least one motion control device, comprising: a set of motion dataitems, where each motion data item is either a primitive data item whichis stored on a motion control device and cannot be emulated by using thevalue of at least one other motion data item, or a non-primitive dataitem that does not meet the definition of a primitive data item; amotion control device capable of storing at least one motion data item;a set of selectable first software modules, where each selectable firstsoftware module is associated with at least one motion control device,is capable of communicating with at least one associated motion controldevice, and exposes a first interface, where the first interface isassociated with a first identifier used to acquire the first interface,is capable of being used while communicating across software processes,and contains at least one program element that is associated with atleast one motion data item, where at least one selected first module isselected from the set of selectable first modules and configured toexchange data with at least one motion control device; a second module,where the second module exposes a second interface, where the secondinterface is associated with a second identifier used to acquire thesecond interface, is capable of being used while communicating acrosssoftware processes, and contains at least one program element that isassociated with at least one motion data item, uses the first interfaceto exchange at least one motion data item with the at least one selectedfirst module; and a third module that uses the second interface exposedby the second module to communicate at least one primitive motion dataitem or at least one non-primitive motion data item with the secondmodule.
 160. A system as recited in claim 159, in which the definitionof the first interface exposed by the at least one selected first moduleis acquirable.
 161. A system as recited in claim 160, further comprisingan operating system, where the definition of the first interface isacquirable from the operating system.
 162. A system as recited in claim160, in which the definition of the first interface is acquirable fromthe at least one selected first module.
 163. A system as recited inclaim 159, in which the first and second interfaces are the same.
 164. Asystem as recited in claim 159, further comprising a network system,where the third module and the second module are capable ofcommunicating across the network system using the second interface. 165.A system as recited in claim 164, in which the first and secondinterfaces differ.
 166. A system as recited in claim 164, furthercomprising a network system, in which the second module and the at leastone selected first module are capable of communicating across thenetwork system using the first interface.
 167. A system as recited inclaim 164, further comprising a network system, in which the thirdmodule and the second module are capable of communicating with eachother using the second interface across the network system and thesecond module and the at least one selected first module are capable ofcommunicating with each other across the network system using the firstinterface.
 168. A system as recited in claim 159, in which at least oneprogram element within the first interface is comprised of a function.169. A system as recited in claim 159, in which at least one programelement within the first interface is comprised of a parameter.
 170. Asystem as recited in claim 159, in which at least one selectable firstmodule is capable of exchanging data with at least one motion controldevice and causing at least one motion data item to be read from themotion control device.
 171. A system as recited in claim 159, in whichat least one selectable first module is capable of exchanging data withat least one motion control device and causing at least one motion dataitem to be written to at least one motion control device.
 172. A systemas recited in claim 159, in which at least one selectable first moduleis capable of exchanging data with at least one motion control deviceand causing the motion control device to move an object.
 173. A systemas recited in claim 159, in which at least one selectable first moduleis capable of exchanging data with at least one motion control deviceand causing the motion control device to move.
 174. A system as recitedin claim 159, in which at least one selectable first module isselectable using a user interface.
 175. A system as recited in claim159, in which at least one selectable first module is programmaticallyselectable.
 176. A system as recited in claim 159, in which at least oneselectable first module is a software component.
 177. A system asrecited in claim 159, in which the second module is a softwarecomponent.
 178. A system as recited in claim 159, in which the secondmodule is an application.
 179. A system as recited in claim 159, inwhich the third module is an application.
 180. A system for exchangingdata with at least one motion control device, comprising: a set ofmotion data items; a motion control device capable of storing at leastone motion data item; a set of selectable first modules, where theselectable first modules are each associated with at least one motioncontrol device, are each capable of communicating with at least oneassociated motion control device, and each exposes a first interface,where the first interface is associated with a first identifier used toacquire the first interface, is capable of communicating across softwareprocesses, and contains at least one program element that is associatedwith at least one motion data item, where at least one selected firstmodule is selected from the set of selectable first modules andconfigured to exchange data with at least one motion control device; asecond module, where the second module exposes a second interface that:is associated with a second identifier used to acquire the secondinterface, is capable of communicating across software processes, andcontains at least one program element that is associated with at leastone motion data item, and uses the first interface to communicate atleast one motion data item with at least one selectable first module;and a third module that uses the second interface to exchange at leaseone data item with the second module.
 181. A system as recited in claim180, in which the definition of the first interface is acquirable. 182.A system as recited in claim 181, in which the first and secondinterfaces are the same.
 183. A system as recited in claim 181, furthercomprising an operating system, where the definition of the firstinterface is acquirable from the operating system.
 184. A system asrecited in claim 181, further comprising an operating system, where thedefinition of the first interface is acquirable from the at least oneselected first module.
 185. A system as recited in claim 180, in whichthe first and second interfaces differ.
 186. A system as recited inclaim 185, further comprising a network system, where the third moduleand the second module are capable of communicating with each otheracross the network system using the second interface.
 187. A system asrecited in claim 185, further comprising a network system, where thesecond module and the at least one selected first module are capable ofcommunicating with each other across the network system using the firstinterface.
 188. A system as recited in claim 185, further comprising anetwork system, where the third module and the second module are capableof communicating with each other across the network system using thesecond interface; and the second module and the at least one selectedfirst module are capable of communicating with each other across thenetwork system using the first interface.
 189. A system as recited inclaim 185, in which each motion data item is either a primitive dataitem which is stored on a motion control device and cannot be created byusing a value of at least one other motion data item, or a non-primitivedata item that does not meet the definition of a primitive data item.190. A system as recited in claim 189, in which the third module usesthe second interface to exchange at least one primitive motion data itemand at least one non-primitive motion data item with the second module.191. A system as recited in claim 189, in which the third module usesthe second interface exposed by the second module to exchange at leastone primitive motion data item with the second module.
 192. A system asrecited in claim 189, in which the third module uses the secondinterface to exchange at least one non-primitive motion data item withthe second module.
 193. A system as recited in claim 185, in which atleast one program element within the first interface is comprised of afunction.
 194. A system as recited in claim 185, in which at least oneprogram element within the first interface is comprised of a parameter.195. A system as recited in claim 185, in which at least one programelement within the first interface is comprised of a variable.
 196. Asystem as recited in claim 180, in which the at least one selected firstmodule is capable of causing at least one motion data item to be readfrom at least one motion control device.
 197. A system as recited inclaim 180, in which the at least one selected first module is capable ofcausing at least one motion data item to be written to at least onemotion control device.
 198. A system as recited in claim 180, in whichthe at least one selected first module is capable of exchanging at leastone motion data item with at least one motion control device to causethe motion control device to move an object.
 199. A system as recited inclaim 180, in which the at least one selected first module is capable ofexchanging at least one motion data item with at least one motioncontrol device to cause the motion control device to move.
 200. A systemas recited in claim 180, in which at least one selectable first moduleis selectable using a user interface.
 201. A system as recited in claim180, in which at least one selectable first module is programmaticallyselectable.
 202. A system as recited in claim 180, in which at least oneselectable first module is a server component.
 203. A system as recitedin claim 180, in which the second module is a server component.
 204. Asystem as recited in claim 180, in which the second module is anapplication.
 205. A system as recited in claim 180, in which the thirdmodule is an application.
 206. A system for exchanging data with atleast one motion control device, comprising: a set of motion data items;a motion control device capable of storing at least one motion dataitem; a set of selectable first modules, where each selectable firstmodule is associated with at least one motion control device, is capableof communicating with at least one associated motion control device, andexposes a first interface, where the first interface is associated witha first identifier that allows the first interface to be acquired,employs a replaceable proxy stub to communicate across softwareprocesses over a network without changing any of the selectable firstmodules that expose the first interface, and contains at least oneprogram element that is associated with at least one motion data item,where at least one selected first module is selected from the set ofselectable first modules and configured to communicate with at least onemotion control device; a second module configured to communicate withthe at least one selected first module using the first interface toexchange at least one motion data item between the second module and theat least one selected first module; a third module configured tocommunicate with the second module to exchange at least one motion dataitem with the second module.
 207. A system as recited in claim 206, inwhich a definition of the first interface is acquirable.
 208. A systemas recited in claim 207, further comprising an operating system, where adefinition of the first interface is acquirable from the operatingsystem.
 209. A system as recited in claim 207, in which a definition ofthe first interface is acquirable from the at least one selected firstmodule.
 210. A system as recited in claim 206, further comprising anetwork system, where the third module and the second module are capableof communicating with each other across the network system using asecond interface exposed by the second module.
 211. A system as recitedin claim 210, in which the first and second interfaces are the same.212. A system as recited in claim 210, in which the first and secondinterfaces differ.
 213. A system as recited in claim 206, furthercomprising a network system, where the second module and the at leastone selected first module are capable of communicating with each otheracross the network system using the first interface.
 214. A system asrecited in claim 206, further comprising a network system, where thethird module and the second module are capable of communicating witheach other across the network system using the second interface and thesecond module and the selectable first module are capable ofcommunicating with each other across the network system using the firstinterface.
 215. A system as recited in claim 206, in which each motiondata item is either a primitive data item which is stored on a motioncontrol device and cannot be emulated by using a value of at least oneother motion data item; or a non-primitive data item that does not meetthe definition of a primitive data item.
 216. A system as recited inclaim 215, in which the third module uses the second interface toexchange at least one primitive motion data item and at least onenon-primitive motion data item with the second module.
 217. A system asrecited in claim 215, in which the third module uses the secondinterface to exchange at least one primitive motion data item with thesecond module.
 218. A system as recited in claim 215, in which the thirdmodule uses the second interface to exchange at least one non-primitivemotion data item with the second module.
 219. A system as recited inclaim 206, in which at least one program element is a function.
 220. Asystem as recited in claim 206, in which at least one program element isa parameter.
 221. A system as recited in claim 206, in which at leastone program element is a variable.
 222. A system as recited in claim206, in which the at least one selected first module is capable ofcausing at least one motion data item to be read from at least onemotion control device.
 223. A system as recited in claim 206, in whichthe at least one selected first module is capable of causing at leastone motion data item to be written to at least one motion controldevice.
 224. A system as recited in claim 206, in which the at least oneselected first module is capable of causing at least one motion controldevice to move an object.
 225. A system as recited in claim 206, inwhich the at least one selected first module is capable of causing atleast one motion control device to move.
 226. A system as recited inclaim 206, in which at least one first selectable module is selectableusing a user interface.
 227. A system as recited in claim 206, in whichat least one selectable first module is programmatically selectable.228. A system as recited in claim 206, in which at least one selectablefirst module is a server component.
 229. A system as recited in claim206, in which the second module is a server component.
 230. A system asrecited in claim 206, in which the second module is an application. 231.A system as recited in claim 206, in which the third module is anapplication.